She writes about it at Product Ops Confidential on Substack and talks about it at conferences, and she is direct in a way that makes the conversation genuinely useful rather than just reassuring.

This episode covers what product ops actually is, why it keeps getting misread, how to make the case for it when leadership is not feeling the pain, and what the relationship with research ops can look like at its best. It also gets into the part nobody talks about enough: how small, concrete problems have a habit of leading you somewhere much larger and more uncomfortable once you start digging.

Not just templates and Confluence tidying

Antonia’s working definition of product ops has shifted over the years. Early on, she leaned on the “I make your life easier” pitch — which is not wrong exactly, but undersells the role and sets up the most common misconception: that product ops is just about process. Templates. Reordering Slack channels. Making Confluence navigable.

“It was very easy to vilify,” she says. “People would say: more process doesn’t equal better, so why have a role that only introduces more process on top of more process?”

The way she frames it now is different: having repeatable systems for high-impact work. Product work is complex by nature — you’re solving hard problems in service of both customers and the business, with a huge number of moving parts. Product ops is about making sure that can happen effectively, and that it can keep happening, without burning people out or breaking every time the team grows.

Low-value operational work — the Confluence tidying, the Slack reorganising — is not nothing, she acknowledges. Those things cause real pain. But when time is limited, which it always is, they are a trap. “The less time you have, the more intentional you need to be about what operational work you actually take on. You need to anchor yourself to what actually moves the needle for the business.”

Would you rather listen to this on the go? Check out the full episode on Spotify

The discipline that almost got cut — and what survived

The early hype around product ops was real. It was on every podcast, at every conference. Then the economic downturn hit, and enabling roles — product ops, research ops, design ops — were among the first to go.

What has come out the other side is more interesting than what went in. The conversation has matured. The concept is better understood. But the question has shifted: rather than “should we hire for this?”, more organisations are now asking “how do we do this without adding headcount?”

Antonia sees this as progress. “Product ops tasks have always existed,” she says. “The advent of this new role didn’t randomly, magically pull out new things for us to do. There was always somebody doing this work. The question is whether you do it intentionally.” That intentionality — not the headcount — is the real differentiator between teams whose operating system happens to them and teams who design it themselves.

Bottom up, until it isn’t

Historically, the demand for product ops has come from the people closest to the work. They are the ones who feel it first: the PMs who cannot access customer data, the teams spinning their wheels in misaligned meetings, the individuals who have to chase an answer across half a dozen Slack threads just to move an inch. But those same people rarely have the budget authority to do anything about it.

“The pain needs to grow and grow until it hits a head of product who is like, ‘my teams are drowning’,” Antonia explains. “And then that needs to be painful enough for the head of product to go to the CPO and say: we need to do something about this.”

What struck her early in her career was where the resistance came from. Standard PMs, the ones living the problem day to day, immediately got it. CPOs were a different story — often dismissing the need with “our PMs should be handling this” or “I already have people for that.” They simply were not feeling the same pain.

That is changing, slowly. The rise of the “product operating model” as a concept has pushed more senior leaders to think about ways of working as something that can be a genuine asset or a genuine liability. Top-down recognition is becoming more common. But the bottom-up signal remains the more reliable ignition.

Selling it upwards: from team pain to business pain

Getting buy-in is the part of enabling work that trips people up most often, and Antonia is direct about why: team pain is not a compelling enough argument on its own.

“Saying ‘our PMs are overwhelmed’ or ‘they can’t access customer insights’ — yeah, that sucks. But a CPO has five other dumpster fires. Do you want to take a look at those too?”

The shift that works is reframing the problem at the business level. What is this costing the organisation? What opportunities are being left on the table? How far ahead is the competition getting while internal friction slows things down? That is the language that lands with budget holders — and it is a lesson she says applies equally to research ops, design ops, and any role that exists to enable others rather than ship features directly.

Research ops and product ops: a relay race, not a turf war

In her first full-time product ops role, Antonia had a research ops team as a counterpart — and she describes it as one of the better working relationships she has had. The research ops team built depth: libraries of methods, guidance on how to involve the right people, frameworks for speaking to customers. Product ops picked up from there, helping teams take what they had learned and turn it into something actionable for actual product decisions.

“It was like passing a baton,” she says. “They had done the hard work of building and organising the knowledge. We could then ask: now what do you do with it? How do you frame it in a way that actually moves the product forward?”

That setup is rare, though. Most organisations have one or the other. When that’s the case, whoever is in the room tends to stretch. A product ops person might dig into research repositories and make sure they are actually indexed and used. A researcher might go further into the decision-making layer. Neither needs to cover the full spectrum of the other — but the overlap is more productive than people expect.

Her advice for researchers working alongside a product ops person: treat them as the systems thinker. “That is a superpower they have — and it’s something they can extend to your work too. You know the research domain inside and out. They know how to formalise and scale things. When those two things combine, the whole product organisation benefits.”

The inflection point: roughly eight PMs

When does a team actually need to hire for this? Antonia’s answer is genuinely “it depends” — but she offers a useful rule of thumb. A company with a strong early product founder who was deliberate about ways of working from day one may never need a dedicated ops hire. A company that scaled fast, through acquisition or hypergrowth, with knowledge living mostly in people’s heads and nothing written down, may need one sooner than they think.

The inflection point she sees most often is around eight product managers. That’s when it becomes genuinely hard to just get everyone in a room and sort things out. For research teams, she puts it slightly earlier — around five or six — given the volume and variety of what researchers produce.

Digging until you hit the real problem

When Antonia goes into an organisation to look at its operating model, she starts with two questions: what is painful today, and where does the organisation want to go? Two areas that surface almost every time are strategy execution and data utilisation — not just whether people access data, but whether that data is actually shaping decisions at any meaningful level.

But the diagnostic work has a habit of escalating. You start with something small and concrete, and you dig. She tells the story of being asked to get more people to read the internal newsletter. Simple enough. Except the more she looked into it, the more she realised communication was broken across the entire company — not a newsletter problem at all.

“The root cause is often cultural,” she says. “You might start with something clearly defined and end up realising the organisation works in a way where everything comes top-down and teams aren’t actually empowered. That has very little to do with the original problem anymore.”

Getting permission to solve the bigger thing — rather than just the presenting symptom — requires evidence. You have to show your work: here is where I started, here is what I found, here is where it led. Do it well, and you get to fix the actual problem. Skip it, and you’ve dug a bigger hole while the newsletter remains unread.

Three things, kept simple

Asked what she would tell a product manager who wants to improve how their team operates — without a budget, without a hire, just with what they already have — Antonia keeps it tight.

Be intentional about how you get work done. Your operating system either happens to you or you design it. One of those feels better than the other.

Be ruthless with your time. You can only solve one problem at a time, especially when this is not your full-time job. Pick the one that actually matters.

Trust your intuition. “You already know what’s wrong. You’ve already felt it.” Follow that feeling to the root cause, because there is always something underneath it.

It is advice that travels well beyond product management. Anyone in a role that exists to make complex work run more smoothly — researchers, designers, ops people of any flavour — will recognise the same pressures and the same path forward.

Antonia Landi can be found on LinkedIn and writes at Product Ops Confidential on Substack.

The premise was simple. I had already conducted user interviews myself (the “human moderator” condition), and then I had an AI conduct similar interviews with real users. The question: how do they compare, and where does each approach shine?

The Waltz vs. The March

The most striking difference came down to style.

Human moderators dance. We start with question one, jump to question eight, circle back to five, improvise a follow-up that wasn’t in the script, and somehow land on something meaningful. It’s a waltz—fluid, responsive, occasionally chaotic.

AI moderators march. Question one, question two, follow-up, question three. They stay structured, stay on track, and rarely stray from the sandbox they’ve been given.

This isn’t inherently good or bad—it’s a trade-off. If you’re running exploratory research where you need to chase unexpected threads, the human waltz is invaluable. If you have a defined scope and just need specific answers, the AI’s discipline can be a feature, not a bug.

The Context Gap

Here’s where humans still have a clear edge: contextual awareness.

Think about your typical week as a researcher. You’re embedded in your organization. You know that Team A is worried about onboarding friction, Team C is planning a feature launch next quarter, and leadership is quietly nervous about retention. When you interview users, all of this context sits in the back of your mind, shaping which threads you pull.

An AI doesn’t have this. It operates in a vacuum—a sandbox focused purely on the questions you’ve given it. It won’t notice when a user mentions something relevant to Team C’s upcoming project, because it doesn’t know Team C exists.

This matters more than you might think. Contextual awareness is what makes research output rich—not just answering the original question, but surfacing insights that spark new conversations, build cases for future studies, and connect dots across the organization.

The Rapport Question

This one caught me off guard.

Watching the AI-moderated sessions, I noticed something: many participants seemed... less engaged. There was no rapport, no shared laughter, no sense of genuine conversation. Even with AI voices that sound remarkably human, something was missing.

But here’s the twist: younger demographics didn’t seem to mind as much.

The drop in engagement wasn’t universal. Younger users kept talking, kept sharing, seemed largely unbothered by the artificial moderator. This raises an interesting question for the future: as people become more accustomed to AI interactions, will this rapport gap narrow? Will future generations find it perfectly natural to be interviewed by a machine?

I don’t have a definitive answer, but it’s worth watching.

The Fraud Problem

There’s a practical concern that doesn’t get discussed enough: fraud detection.

Human moderators develop instincts. We notice when something feels off—when answers seem rehearsed, when someone’s clearly not who they claim to be, when the BS meter starts pinging. We can make real-time judgments and flag problematic participants.

AI moderators don’t have this radar. To compensate, you’d likely need heavier screening upfront—more detailed qualification questions, stricter criteria. But here’s the irony: if you’re spending all that extra time on screening, you might end up neutralizing the time savings that made AI moderation attractive in the first place.

It’s a hidden cost worth factoring into your calculations.

Knowing When to Press

Great interviewers know when to push. A user gives a surface-level answer, and something tells you there’s more beneath it. You rephrase the question. You approach it from a different angle. You wait in comfortable silence until they fill the gap.

This intuitive pressing—knowing when and how to dig deeper—is something AI still struggles with. Yes, you can bake follow-up questions into your script, but it’s awkward. Sometimes those probes aren’t needed. Sometimes they’re needed but weren’t anticipated. The human judgment of “there’s something here worth exploring” is hard to automate.

So Where Does AI Moderation Actually Shine?

After running these experiments, I don’t see AI moderation as a replacement. I see it as a tool with specific, valuable use cases:

1. Narrow, well-defined scopes. When you have a tight sandbox—specific questions, specific goals, no need to explore tangents—AI handles it beautifully. The structure becomes a feature.

2. Getting a head start. Starting a project from scratch with limited understanding? Send out AI-moderated interviews first. Use those initial results to inform how you design the deeper, human-led research that follows. It’s reconnaissance before the full campaign.

3. Open-ended questions at scale. Need to ask three or four open questions to a large sample? AI can run these conversations in parallel, gathering breadth that would take you weeks to achieve solo.

4. Time crunches (with a caveat). Sometimes it’s “something or nothing.” Tight deadlines, no time for proper qualitative depth—AI moderation can give you some signal when the alternative is flying blind.

But be careful here. This is an escape hatch, not a default. The moment “we don’t have time” becomes your standard justification, you’ve stopped doing research and started doing something that just looks like research.

The Real Opportunity: Combination

The most exciting possibility isn’t AI or human moderation—it’s learning to combine both strategically.

Use AI for the structured, scalable, bounded work. Use humans for the exploratory, contextual, rapport-dependent work. Let AI give you a head start, then bring human judgment for depth. Run AI-moderated sessions alongside human ones to increase coverage without burning out your team.

The researchers who figure out this orchestration—knowing which tool for which job—will be able to learn more, faster, with limited resources.

Final Thoughts

AI moderation is real, and it’s improving. Unlike synthetic users (which I remain skeptical about), I think there’s genuine potential here for augmenting research practice.

The key is honesty about trade-offs. AI won’t replace the human waltz anytime soon. It won’t pick up on organizational context or build genuine rapport. It won’t catch the fraudsters or know intuitively when to push harder.

But it doesn’t need to do everything. It just needs to do something well enough to earn a place in your toolkit.

Why Speed Matters in Research

One of the most common tensions I hear from researchers is the struggle with speed. The business moves too fast, stakeholders are impatient, and there’s never enough time for proper research. But Ari offers a different perspective that completely reframes this challenge.

“People think that speed and rigor are at odds,” Ari explains. “That’s not necessarily the case. What speed means is time to learning, not time to end learning.”

The traditional research model existed because the risk of being wrong was worse than the risk of being slow. Software used to be shipped in boxes and placed on shelves—once it was out there, you couldn’t update it. You had to get it right the first time.

But that world doesn’t exist anymore. Products can be updated constantly, yet research hasn’t adapted to this new reality. Instead of reimagining the process, many teams simply compressed the traditional linear academic approach. The same process that took eight weeks now takes three weeks—but it’s still plagued by the same fundamental problems.

The Real Cost of Slow Research

Ari makes a compelling point about the economics of research speed: engineering teams are a fixed cost. Whether those engineers are coding or sitting around eating bagels, the business is paying for them. When research can’t keep pace, product teams face a choice: wait for research or move forward anyway and fix things later.

We all know what usually happens—they move forward. And then research ends up working the product roadmap, always lagging behind. This creates two predictable outcomes: either you validate what’s already been decided (and product managers celebrate being right), or your findings contradict the plan (and suddenly your sample size is too small or your methods are questioned).

The Backhoe vs. The Shovel

Ari offers a brilliant analogy to illustrate the difference between old and new approaches to research:

“Imagine I buried a gold coin in my backyard and asked you to help me find it. You could take a backhoe and dig one big hole, then deliver all that dirt to me so I can sift through it to find the coin. Or you could take an abductive approach—with every shovel scoop, we learn from it. It’s not here? Cool, let’s change locations. Not here either? Let’s adjust again.”

This is what research needs to become: an ongoing learning process rather than something with a finite endpoint. Instead of one massive study that delivers results weeks later, we should be learning continuously and sharing insights as we go.

The Democratization of Research: Friend or Foe?

The democratization of research is happening whether we like it or not. But I recently came across a study showing that researchers’ fears about democratization have shifted. The top concerns are no longer about whether non-researchers should be doing research at all, but rather:

• Cherry-picking results

• Missing important connections in the data

• Bias in presenting findings

In other words, researchers worry that stakeholders will manipulate research to support whatever story is most convenient for them.

Attacking the Wrong End of the Problem

Ari points out that we’re often attacking the front end of this problem—trying to teach people better methods and more rigorous approaches. But there’s a more fundamental shift that needs to happen in how we think about evidence and argumentation.

He breaks down three types of arguments:

Arguments of blame: “Why did you only do five interviews?”

Arguments of value: “Quantitative methods are way stronger than qualitative methods.”

Arguments of choice: “Given what we know today, where should we go in the future?”

Only the last one is truly useful. When researchers engage in blame and value arguments, we create conflict rather than collaboration. Instead, we should be focusing on evidence and decision-making.

“If you came to me with a point of view and I came to you with a point of view, we should be able to say, ‘Oh, that’s tacit knowledge—I have a low level of certainty on that evidence. I have a higher level of certainty on this. What do we need to do to move forward?’”

Making Room for Imperfect Evidence

This approach allows someone who’s had two sales conversations to still bring that evidence to the table, because it’s meaningful to them. Rather than being completely dismissive, you acknowledge it as evidence with unexamined assumptions—lower certainty, yes, but still valuable when corroborated with other sources.

This creates a dialectic rather than a debate. You share information together to reach a shared viewpoint focused on the future, not arguing about what methods should have been used in the past.

As Ari puts it: “We deal with the quality of evidence on the backend, because not all evidence is created equal. You could have a bad interview that still yields good insight, just like you could have a great interview that yields bad insight.”

AI and the Future of Research

Of course, we can’t talk about the future of research in 2025 without discussing AI. I’ve noticed the research community is pretty split—some people are scared, others see huge opportunities, and many are still trying to figure out how to use these tools in their daily work.

Ari’s perspective is refreshingly pragmatic. He frames it around the three parameters of the research program of the future: faster, cheaper, and good enough rigor.

Where AI Can Help Today

AI can create efficiencies in analysis and help make research more accessible. One example Ari mentions really resonated with me: “Academics love to write at a 12th grade level. Maybe AI could help you write at a fifth grade level, which will help your audiences better understand what you’re talking about.”

AI is also enabling cheaper solutions—searchable repositories that work like Perplexity but for your internal research, reducing operating expenses while making insights more accessible.

Looking Forward, Not Just at Today

“We could evaluate AI in terms of what it can do today for research,” Ari notes, “but I don’t think that’s really where we should be looking. It’s what is it going to do tomorrow?”

The interview tools available now aren’t as good as human interviewers—not even close. But are they good enough for some things? Sure. And they’re getting better rapidly.

The question isn’t “should we use AI or not?” It’s “how can we use it to improve in collecting, connecting, and communicating in a way that’s faster, cheaper, and with good enough rigor?”

Becoming a “consigliere” to the Business

One of my favorite concepts from Ari’s work is this idea of the researcher as consigliere—the trusted advisor who provides counsel to the business. But how do you actually become that person when you’re stuck running usability tests and deciding whether buttons should be red or green?

Ari’s answer is both simple and profound: Just do it.

Act As If You Already Belong

He references William James, the father of American psychology, who said that if you want to be seen as something, act as if you already had that quality.

“Stop asking for permission and instead ask for feedback. When you’re asking for a seat at the table, you don’t get a seat at the table. But when you pull up the chair and sit down, it’s just assumed that the seat was yours.”

Act as if you belong in those conversations. Start interjecting yourself. Show the business how your work connects to growth, value, adaptability, risk, and speed. Demonstrate how your research helps capture or keep more customers and ultimately drives revenue.

Everything Can Be Strategic

This connects to something I feel strongly about—the false dichotomy between “tactical” and “strategic” research. Ari completely dismantles this distinction:

“Using the word strategic to say this is important totally minimizes the work that everybody else does. Strategy is defined as having an intense focus on the things that matter most. All research by nature is strategic.”

A usability test might be strategic from a UX perspective, but it could also be strategic to the business in other ways. And all research is tactical too—you have to collect data, connect the dots, and communicate findings. Those are tactics.

By creating these artificial hierarchies, we’re cutting our own legs out from under us.

Three Tips for the Researcher of the Future

I asked Ari for concrete advice for researchers who want to transform their practice but don’t know where to start. His three tips perfectly encapsulate everything we discussed:

1. Collect Evidence Like a Detective

Take an abductive approach to evidence gathering. Yes, think about methods, but remember that five methods account for the majority of the work. Focus on continuous learning rather than perfect methodology.

2. Build Cases, Not Just Reports

Think like a detective building a case. How do you construct “likely event” stories? How do you take data and turn it into stories, stories into strategies, and strategies into outcomes? Build narratives that help the business move forward.

3. Become a Better Communicator

This is the number one thing you can do. The better you can communicate insights, explain problems, articulate desired outcomes, and present solutions with supporting evidence, the better you’ll be.

As Ari explains: “The better you can tell stories that show ‘I’ve identified this problem, we want to get to this outcome, we’ve got this solution as the bridge, here are the tactics and evidence to support that, and here are the risks of action and inaction’—the better you’re going to be and you’ll be seen as the expert that you really are.”

Final Thoughts

What strikes me most about this conversation is how Ari reframes challenges as opportunities. Speed isn’t the enemy of rigor—it’s about continuous learning. Democratization isn’t a threat—it’s a chance to elevate the conversation about evidence. AI isn’t replacing researchers—it’s a tool we can leverage to do our jobs better.

And perhaps most importantly, we don’t need to wait for permission to become strategic advisors to our organizations. We just need to start acting like we already are.

The Shift from Collection to Connection

Research is undergoing a fundamental transformation. Rather than serving primarily as data collectors, researchers need to become data connectors—bridging different business units and connecting people to the information they need to make better decisions faster.

This shift isn’t universally accepted yet. Many researchers still cling to traditional methods, much like typing pools resisted word processors in the 1950s. The field has long viewed itself through an academic lens, prioritizing rigorous methods and linear processes that culminate in publication. But businesses don’t necessarily need what researchers have been delivering.

Would you rather listen to this on the go? Check out the episode on Spotify:

The New Reality: Faster, Cheaper, Good Enough

The research teams that will thrive in the future will operate differently. They’ll move faster, cost less, and deliver “good enough” rigor. This doesn’t mean abandoning rigor altogether—it means aligning the level of rigor with the type of question being asked.

Consider the economic realities at play:

Incentive structures: Product and engineering teams are measured on shipping product, not conducting research. Anything that slows down shipping will be pushed aside.

Scarcity: Limited resources mean businesses invest where they get the biggest return.

Opportunity cost: Every dollar spent on research is a dollar not spent elsewhere.

These aren’t abstract concepts. Over the past few years, researchers have been laid off, programs have been cut, and new tools promise research capabilities at lower costs.

Research as Both Noun and Verb

Here’s an uncomfortable truth: people are already doing research without researchers. Startups don’t hire researchers in their first 10 to 20 employees. Yet Amazon, Apple, and every successful company today started small and found success before building large research teams.

Research is both a person and an action. Treating non-researchers as children who need guardrails and governance is not only ineffective—it’s insulting. These same people were conducting research before researchers arrived, and they’ll continue doing so whether researchers help them or not.

The Big Five Methods

When it comes to research methods, the Pareto principle applies. Five fundamental methods can cover the vast majority of research needs:

1. Interviews

2. Basic surveys

3. Desk research

4. Usability or concept testing

5. Observation

These five methods could sustain an entire research career. While specialized techniques like conjoint analysis or MaxDiff have their place, most research questions don’t require them. And when they do, researchers can partner with vendors or specialists.

Becoming a Trained Observer

The future researcher isn’t just a data collector—they’re a trained observer who can:

1. Collect evidence using foundational methods

2. Connect the dots through abductive reasoning to build a case

3. Strategically communicate findings in ways that drive action

Most researchers fail at the third step. They compile findings into lengthy decks, present them in hour-long readouts, and then file them away in repositories where they’re forgotten forever.

The Hollywood Model of Communication

Think about how movies are released. First comes a trailer that helps you decide if you want to see the full film. If you love the movie, you might watch the director’s cut with extras. You might explore the actors’ other work or dive deep into production details on IMDB.

At no point does the theater force you to watch the director’s cut first.

Research communication should follow the same layered approach:

• The trailer: Headline findings that grab attention

• The feature film: Deeper insights for those who want more

• The extras: Source data and detailed methodology for those who need it

Release information as a “choose your own adventure” rather than requiring everyone to wade through everything. Data shows that research decks peak in views within the first 48 hours, then are rarely accessed again. The traditional approach simply doesn’t work.

Connecting to What Matters

Researchers often leave the business impact of their work implicit, expecting stakeholders to connect the dots themselves. This is a critical mistake.

Every business fundamentally cares about five things:

1. Growth: Expanding the business

2. Value: Increasing worth for customers and the company

3. Adaptability: Responding to change effectively

4. Risk: Mitigating potential downsides

5. Speed: Moving faster than competitors

All other metrics ladder up to these five priorities. When researchers explicitly explain how their findings impact these areas, they become exponentially more valuable to the organization.

Research isn’t about “getting a seat at the table” or “being part of the decision-making process.” It’s about connecting work to what actually moves the needle for the business.

The Path Forward

The researchers who will succeed are those who embrace this evolution. They’ll focus less on perfect methodology and more on providing the right level of insight at the right time. They’ll empower others to conduct research while positioning themselves as expert guides who help make sense of all available evidence.

They’ll communicate strategically, not comprehensively. And they’ll always tie their work back to the five things every business cares about most.

The choice is clear: evolve or be left behind. The research function is changing whether individual researchers embrace it or not. The question isn’t whether this transformation will happen—it’s whether you’ll be part of shaping what comes next.

Like most things that sound too good to be true, these “users” come with significant limitations that researchers need to understand.

IMPORTANT: During the episode, I use terms like AI-users and synthetic users interchangeably. In every case, I’m generically referring to AI-generated users and not specifically to the brand “Synthetic Users”.

Would you rather listen to this on Spotify? Find it here:

The Experiment: Testing AI-Users Against Reality

To move beyond hype and subjective impressions, I decided to test AI-users rigorously. Rather than relying on anecdotal success stories, I created a controlled environment to compare AI-manufactured users with real humans and understand where each adds value.

Here’s what I did: I selected four large language models (GPT, Mistral, and Llama in local versions, plus Claude) and created identical personas across all of them.

I fed these models a curated dataset based on actual research from a project I ran a couple of years ago (with all personally identifiable information removed and realistic synthetic data added). Then I recruited real users matching those same personas and conducted interviews with both groups.

The comparison revealed something crucial: synthetic and human answers are fundamentally different.

The Gap Between Machine and Human Answers

When AI-users respond to interview questions, their answers tend toward best-case scenarios. Everything unfolds as expected. Answers are straightforward, linear, and optimized. Humans? They’re messier, more emotional, more contradictory and far more realistic.

Consider a simple question: “Tell me about the last time you went to the gym.”

An AI-user might respond: “Last time I went to the gym was Tuesday at 7 AM. I trained for 45 minutes and did pull-ups, bench press, then legs.”

A human’s answer sounds more like: “Well, last week I wanted to go weekly, but work was crazy. I managed to go once instead of twice because my kid got sick. The previous week wasn’t much better...”

The human answer reveals scheduling challenges, life interruptions, and competing priorities. Which is actually the real context that shapes gym experience and informs meaningful design decisions.

The Supportiveness Problem

Another pattern emerged: AI-users sometimes operate in extremes. Ask them to evaluate a design, and they either become unrealistically supportive (praising even really crappy ideas) or enter a suggestion loop where they continuously identify things to improve, non-stop.

Real users don’t work this way. Some are naturally positive and avoid criticism to spare feelings, but most offer a nuanced mix of feedback. More importantly, the richness and contradictions in human responses contain the insights researchers need. The tension between what users like and what frustrates them often points to the most valuable opportunities for improvement.

The Data Recency Problem

Here’s where things get genuinely problematic: AI-users are trained on historical data. If your dataset includes outdated information, your AI-users will continue referencing problems that no longer exist.

In the gym example, the facility had recently implemented a locker-booking feature through their app, addressing a long-standing pain point about unavailable lockers. But the AI-users, trained on the older dataset, kept mentioning the locker problem as a current issue. Even when prompted about the change, they sometimes reverted to the old pain point, revealing that the synthetic understanding was frozen in time.

This isn’t a minor issue. It means AI-users can confidently validate solutions for problems you’ve already solved, or suggest improvements to features you’ve already implemented. Without careful data management, you risk getting inaccurate feedback on outdated contexts.

The Real Danger: Checking Boxes Without Rigor

The biggest concern with AI-users isn’t the tool itself, it’s how they could be misused. Research has long faced skepticism and budget pressure. Teams skip research or minimize it, claiming “we don’t have time” or “we know what users need”.

AI-users could become a convenient way to check the research box without doing actual research.

The scenario plays out like this: someone with a predetermined idea uses synthetic users to validate their direction. The AI-generated responses confirm their thinking (especially if framing is persuasive). They then declare, “We did research. Let’s move forward.” The checkbox is marked, but no real learning happened.

AI-users can be manipulated because they’re fundamentally mirrors of their training data and the prompts that guide them. Someone with confirmation bias can shape their questions or context to elicit supportive responses. The result: false validation masquerading as research.

Where AI-Users Actually Add Value

This doesn’t mean AI-users have no place. They do—if used intentionally and within their actual scope.

Protocol refinement: Early in a research process, when you’re drafting an interview guide or study protocol, AI-users can serve as a sparring partner. Conduct a quick 10-15 minute practice interview to stress-test your questions, identify confusing language, and get inspiration for additional questions you hadn’t considered. Then validate with real users before deployment.

Low-stakes skill building: This is perhaps the most underrated use case. Researchers and non-researchers alike benefit from practice environments. AI-users provide 24/7 training grounds with no consequences. New researchers can learn to identify leading questions, biased framing, double-barreled questions, and other common mistakes. Combined with research knowledge training, this could significantly improve the quality of research conducted across organizations.

Imagine a researcher-led training program where team members conduct practice interviews with AI, receive feedback on their technique, iterate, and develop confidence before interviewing real users. The transfer of learning would likely be substantial because they’ve practiced the skill repeatedly and received reinforcement about what works and what doesn’t.

Early ideation: When you’re barely past the whiteboard stage and exploring rough concepts, AI-users can help you think through implications and edge cases. They work as a thinking partner, not a validator.

What AI-Users Cannot Do

AI-users will never replicate the depth, richness, or authenticity of human responses. They’re trained on existing data and existing patterns, they can’t tell you about truly novel use cases, unexpected emotional reactions, or the complicated reality of how people actually live and work. They won’t surprise you. They won’t challenge your assumptions in the way humans do.

Trying to train AI-users to sound more human or more doubtful or more authentic doesn’t solve this problem. It just creates a convincing simulation, which is exactly what you don’t want. You want the real thing.

The Path Forward

AI-users have a legitimate role in research, but it’s a supporting role, not the lead. Use them to explore, refine, and practice. Use them to save time on iteration before you engage real participants. But never use them as a substitute for talking to actual humans.

The teams that will win in product development are those that treat AI-users as a research tool, like a prototype or a wireframe, rather than as a replacement for research. Combine them with rigorous, real-world human research, and you’ll get the best of both worlds: faster feedback loops and genuine human insight.

The future of research isn’t AI-users instead of humans. It’s AI-users alongside humans, each serving their purpose, both working toward better products and better experiences.

Jake’s book addresses something that’s been quietly plaguing research teams for years: we’re sitting on a goldmine of insights that rarely get used beyond their initial presentation. This interview digs into why that happens and, more importantly, what we can do about it.

Want to listen to this on the go? Check out the episode on Spotify!

The Problem: What Is Research Waste?

Before we can solve the problem, we need to define it. Jake takes what he calls a “big tent approach” to research—not just UX research or market research, but anything following a structured research process. This includes work done by data scientists, designers, PMs, and anyone else conducting systematic inquiry.

Within that research, Jake defines insights as “statements backed with evidence from research that are written to influence product planning.” These can be fundamental truths about customers or specific problems to solve.

Research waste, then, is all the insights that don’t get picked up. Maybe they didn’t reach the right audience because a researcher was siloed. Maybe stakeholders agreed with the findings but were too overwhelmed to add them to their backlog. Maybe the timing was just off.

The key realisation: just because research didn’t land immediately doesn’t mean its value is gone. Many insights can influence multiple teams but only reach one or two. The question becomes: how do we activate that latent value?

The Three Root Causes

Rather than offering a one-size-fits-all solution, Jake structures his book around three root causes of research waste. Understanding which one (or combination) is affecting your organization helps you choose the right interventions.

1. Preparation

Different research streams in an organization create an assembly line of individual studies. But there’s much more we could do to prepare our knowledge for long-term use rather than just the moment of the study readout.

Think about it: most research conversations focus on optimizing the study process and that immediate presentation. But what happens after? How do we prepare insights to be useful in future planning decisions across the long haul of product development?

2. Motivation

People often see research as optional or momentary—we learned this, we did something with it (or didn’t), and that’s that. How can we change those motivation structures so researchers see the long-term value of their work, and so stakeholders are motivated to seek out and use existing research?

3. Integration

You can nail preparation and motivation, but if research doesn’t show up when decisions are being made, it won’t have impact. This isn’t just about having a repository—findability isn’t enough. We need strategic touchpoints that push research out and integrate it into planning processes.

As Jake puts it: “We have to find ways to integrate it and push it out there.”

Beyond the Repository Myth

One of the most refreshing aspects of Jake’s thinking is his pragmatic view of research repositories. The industry has long operated under a “build it and they will come” mentality—invest in the perfect repository with exhaustive metadata and sophisticated search, and people will magically start using old research.

It hasn’t worked out that way.

Jake argues we need to work backwards from the impacts we want to have. Where do you actually want research to show up? Monthly business reviews? Design specifications? Specific team roadmaps? Get crisp about those high-value touchpoints, then build your information structures and practices to inject insights at those moments.

“We can’t be everywhere and do everything,” Jake notes. “We have to put on PM hats and prioritize hard—where would research make the biggest difference and how can we get it there?”

It’s Not About “A Seat at the Table”

Another common refrain in the research community is the quest for “a seat at the table.” But as Jake and I discussed, there isn’t just one table. There are dozens of tables, and we can’t be at all of them all the time.

More importantly, it’s not about an individual researcher’s seat at the table—it’s about the collective of researchers contributing to something larger. It’s about creating multiple touchpoints where research can influence decisions, not just hoping for an invitation to the right meeting.

This requires thinking in service design terms: what are the key moments where research could add value? How do we design systems that surface the right insights at those moments?

Three Ways to Get Started

When I asked Jake for his top recommendations for someone wanting to stop wasting research in their organization, he offered three concrete starting points:

1. Look Back and Map What You Have

Take time to review past research and recognize the problem. Talk to other researchers in your organization—find them wherever they are (UX, market research, data science, design). Start mapping what’s already available. You don’t need fancy tools for this; it’s a mindset shift first and foremost.

2. Connect Around Your Studies

When planning a new study, identify three things other folks in your organization might already know something about. Ask: “Does anybody have existing research on this?” Turn study plans into a new kind of research report that says “here’s what we already know” before building to “here’s what we’re going to learn.” Carry that through to your final reporting too.

3. Activate Past Insights in Current Work

Every time you activate insights from a current study, plan to go back and activate relevant past insights for the teams you’re talking to. Check in with stakeholders: “You said you were going to do this based on that previous research—what’s going on?” This breaks the bounds of time-based research units and keeps conversations alive beyond the immediate study window.

These changes won’t add significant time to your work, but they can dramatically increase your impact.

This Isn’t Just for Big Teams

A common objection Jake hears: “I’m at a startup, this doesn’t apply to me” or “We don’t have enough research yet to worry about this.”

His response? The earlier you start, the better positioned you’ll be. When you only have a small volume of research, you can organize it quickly and establish good practices. Wait until you have 55 studies, and the task becomes exponentially harder (like organizing a tea collection that’s gotten out of hand).

More importantly, even small teams can benefit from connecting the dots across research. If you have one data scientist, one UX researcher, and one market researcher, there’s still opportunity to build bridges and increase visibility.

The pain of research waste grows with volume, but the solutions are accessible at any scale.

The Strategic Research Ladder

Everyone wants to do strategic research. It’s become almost trendy to say so. But as Jake points out, when you’re a first researcher or part of a small team, you don’t get there immediately.

Here’s the insight that resonates: you don’t need permission to start building strategic understanding. When answering rapid, tactical questions, add layers that address higher-level concerns. Those additions might not have immediate impact, but they build up over time.

Before you know it, you have strategic standing. When it comes time to provide input to the next round of goals, you have something meaningful to say about many of them—not because you did one big strategic study, but because you’ve been systematically elevating your research questions and connecting insights over time.

Strategic research doesn’t have to be a separate category of work. It can be woven into everything you do.

The Long Game

Perhaps the most important takeaway from my conversation with Jake is this: stopping research waste isn’t a one-and-done initiative. It’s not about finding the perfect tool or implementing one brilliant process change.

It’s long-term change management work that requires persistence and patience.

Start by finding champions and easy wins. Show value in specific, concrete ways. Publicize success stories. Build community around research use. Keep experimenting.

As Jake puts it, the book offers “a menu of possibilities” rather than a single recipe. Your organization needs to figure out which root causes matter most and which interventions make sense for your context.

The goal isn’t to reach 100% research utilization or to inform every decision with research. It’s to get more of the most important decisions informed by the wealth of insights you’ve already generated.

You can find Jake Burghardt on LinkedIn or learn more about his work at integrating research.com. Stop Wasting Research is available from Rosenfeld Media and other major booksellers.

Want more conversations about building better research practices? Subscribe to Finders Builders for weekly insights on research, product, and everything in between.

The Reality Check: You’re Always Outnumbered

Joe has written 10 books on successful UX and Product Design practice, with his latest being “The User Experience Team of One” (second edition), co-authored with Leah Buley. His experience coaching practitioners reveals a harsh truth: most UX teams operate like teams of one simply because of the ratio problem.

“Time, number one. You’re never given enough time to do everything properly and the ratio you just described is part of the problem,” Natoli explains, referencing a coaching client who is a “soul UXR slash UI slash research slash okay, the list goes on” supporting four product lines with large development teams attached to each.

It’s a scenario that sounds familiar to many in the field. But instead of wallowing in the impossibility of the situation, Natoli advocates for a radical shift in approach: embrace small bets and iterative testing.

Listen to the episode on Spotify:

Small Bets, Big Impact

When you’re stretched thin across multiple projects with minimal time, the answer isn’t to attempt grand UX overhauls. Instead, Natoli suggests dividing your limited hours strategically and asking: “What can we iterate on, launch, and then test?”

The key is placing low-risk bets rather than suggesting major changes that could backfire. For enterprise design, this might mean:

• Making primary actions more visually prominent

• Increasing contrast across interfaces

• Adjusting the ratio between headlines, subheads, and body text for better scanning

“You place small bets like that and you test to see if you were right. If you change too much at one time, you’re just inviting new problems,” Natoli notes.

Breaking Free from “Real UX” Dogma

One of Natoli’s biggest frustrations is the industry’s obsession with ideal processes that bear no resemblance to reality. When practitioners can’t follow the prescribed methodologies, they often blame themselves rather than questioning the relevance of those methods.

“A lot of people look at that situation and say, ‘but yeah, but that’s not ideal. Or my favorite: that’s not real UX.’ Of course it is. That’s reality,” he emphasizes.

This disconnect between theory and practice creates widespread imposter syndrome. UX practitioners start believing they’re not good enough because they can’t implement the perfect processes they read about online.

“No one should ever be made to feel less than because of a bunch of shit that they’re seeing that has no grounding in reality,” Natoli states bluntly.

The Collaboration Imperative

Perhaps most importantly, Natoli argues that the solution isn’t better individual processes—it’s better collaboration. The magic happens when teams work together rather than in silos, with everyone contributing their expertise to solve problems collectively.

“You need people embedded in teams together, working together, touching base with each other multiple times a day,” he explains. This means constant communication about constraints, possibilities, and trade-offs.

The enemy of good UX isn’t lack of time or resources—it’s territorial behavior and the word “ownership.”

“Ownership to me is one of the worst words ever used in product design and development of any kind. It should be eradicated from everyone’s vocabulary,” Natoli declares. “You are all there to raise each other up, and you can all be infinitely stronger and more respected if you join forces.”

Three Essential Tips for UX Teams of One

For those feeling overwhelmed by their circumstances, Natoli offers three crucial pieces of advice:

1. Start Anywhere

Paralysis is the enemy of progress. When facing a million problems with no clear priorities, remember composer John Cage’s wisdom: “Start anywhere.” Let the process tell you what needs to happen next rather than trying to plan everything perfectly upfront.

2. Abandon the “Right Way”

Forget about perfect UX methods, ideal research timelines, or prescribed frameworks. “You’re working in an imperfect environment, competing agendas, competing politics,” Natoli reminds us. Instead of asking what should happen, focus on what’s the best you can do under current constraints.

3. Don’t Take It Personally

This is perhaps the hardest lesson. When stakeholders reject your proposals or ignore your advice, it’s not a judgment of your worth. “All you can do is tell the truth. They’re either gonna do it or they’re not. And if they’re not, fine—accept that and move on.”

Don’t waste emotional energy fighting unmovable walls. Redirect that effort toward areas where you can actually make a difference.

The Path Forward

Natoli’s message isn’t one of defeat—it’s one of liberation. By accepting the constraints of real-world UX work and focusing on collaboration over perfection, practitioners can find ways to create meaningful impact even in challenging circumstances.

The goal isn’t to implement every UX best practice perfectly. It’s to work effectively within your constraints, build strong relationships with your teammates, and make incremental improvements that add up to significant change over time.

As Natoli puts it: “We’re better together.” And perhaps that’s the most important UX principle of all.

Joe Natoli is a UX consultant, author, and speaker with over 30 years of experience. He’s the founder of the UX 365 Academy and has helped over 344,000 UX professionals develop their skills. You can find him at givegoodux.com or connect with him on LinkedIn.

Stay tuned and watch this conversation with the one and only Joe Natoli (part 2 coming up next week!).

Disclaimer: this episode summary has been done with the help of AI

The User Experience Team of One, Revisited

When Joe first discovered the original book years ago, his reaction was immediate: "Man, I wish I'd written this book." What struck him was its clarity, honesty, and generous approach, qualities that cut through the artifice and formality often surrounding UX discourse. The book felt like an invitation, making our field accessible to everyone.

I completely understand this reaction because I had the same experience when I read it. This book inspired my transition from researcher to what I'm doing now with Finders to Builders and all my content about researchers becoming solar researchers. It's amazing how certain books can redirect your entire career path.

The updated edition, featuring a foreword by Jesse James Garrett, represents a full-circle moment for Joe, who credits Garrett and Alan Cooper with launching his career three decades ago. As he told me, if someone had predicted this collaboration 30 years ago, he wouldn't have believed it.

Check out the episode on Spotify

Why This Book Still Matters in 2025

During our conversation, I asked Joe why this book remains relevant today. His answer was enlightening: despite technological advances and methodological shifts, the core challenges remain unchanged. We UX professionals are still asked to do more with less—fewer resources, tighter budgets, compressed timelines, and limited organizational understanding of what good UX requires.

What has intensified, Joe explained, is the emphasis on speed. While Agile methodologies promised faster delivery, corporate interpretation often translates to "skip research and go straight to design and build." This rush has derailed what seemed like growing organizational appreciation for user experience work.

As Joe put it: "The minute you say to corporations, 'Hey, this can be faster,' they're like, 'Oh, fast. Yes.' So everything has to be fast now."

Where We're Failing at Communication

I pressed Joe on where he sees UX professionals struggling with communication, and his response was a reality check I wasn't fully prepared for. He identified a critical blind spot: we're too focused on ourselves. We spend excessive time discussing UX principles, processes, and procedures while remaining disconnected from the broader business concerns that drive organizational decision-making.

This hit home for me because I see it constantly online—even from the most trusted organizations and biggest names in our field. We're always talking about UX, always talking about our own stuff. As Joe bluntly stated: "This is not helping."

The harsh reality? When stakeholders say "no" to our research requests or UX improvements, it's rarely about not respecting UX. These decisions often stem from:

• Competing organizational priorities

• Slim profit margins on specific products

• Executive-level constraints we never see

• Structural conflicts built into company hierarchies

Joe's perspective shifted my thinking: "Maybe the larger part of it is the reasons that you're being told no have nothing to do with you, have nothing to do with UX... It has to do with decisions that are made in corner offices by people you've never met."

The Value Loop: A Framework That Changed My Approach

One of the most valuable concepts Joe shared was his "value loop"—something I've written about recently and have started applying in my own work. While we UX professionals rightfully advocate for users, we must acknowledge we're "playing a game on a playing field that has very specific rules"—and those rules center on business value.

Joe explained the cycle:

1. Users find something that appears valuable

2. They try it and receive genuine value

3. They engage further (download, buy, subscribe)

4. The business sees measurable value (money made or saved)

5. The business invests more in improving the product

Both sides must win for the cycle to continue. Joe's controversial but practical stance: "Business first, user second"—not because it's morally superior, but because it's the only path to doing meaningful work for users at scale.

I could see the audience reaction he described when he says this on stage—that moment of "I thought you were on our side." But as he explained to me, and as I've come to understand in my own work: "This is the only way you get to do good things for good people. You gotta convince these people that it's gonna get them what they want as well."

Starting with Nothing: Advice for Scrappy Teams

Since many of my audience members work in teams of one or small teams with limited resources, I asked Joe for practical advice on getting started. His response was characteristically direct: "Do something. Stop complaining about the state of things."

His practical starting points resonated with my own experience:

• Ask for 15 minutes with stakeholders to understand current processes

• Map out "how does this work right now?" with boxes and arrows

• Identify inefficiencies, redundancies, and pain points

• Focus conversations on what takes too long or costs too much

• Ask his favorite question: "What do you want to happen here?"

That last question is gold. As Joe explained, often the real answer reveals personal stakes and fears driving resistance to UX work. Understanding these human motivations opens paths to incremental improvements.

The Inch-by-Inch Strategy That Works

Joe's approach to enterprise UX improvement particularly struck me because it mirrors what I've seen work in my own consulting. Progress happens gradually through tiny wins that build trust:

• Standardize button hierarchies across the system

• Fix alignment issues that create cognitive friction

• Improve error messaging

• Clarify language and labeling

Each small victory demonstrates value and builds credibility for larger UX investments. As Joe told me: "I'm just looking for a positive win, especially when I can't do any research."

His philosophy is refreshingly practical: "I don't care what I have the approval or authority to do. It doesn't ever cross my mind. It doesn't frustrate me. I don't give a shit. What can we get done and how does that show this person that they're gonna get what they want?"

What resonated most with you from this conversation? I'd love to hear your thoughts on the value loop concept and whether you've experienced similar challenges in your own UX work.

If you enjoyed Part 1, you’ll LOVE Part 2. Stay tuned and make sure to subscribe.

But it doesn't have to be this way.

In this in-depth conversation, we sit down with two of the most respected voices in research knowledge management: Emily Di Leo, founder of The Current and former archivist turned UX knowledge management expert, and Alison Jones, the librarian who built Atlassian's legendary research library.

Julian: Before we jump into our main topic, could you both introduce yourselves and tell us what brings you here today?

Emily: I'm Emily Di Leo, and I work in the knowledge management space for UX research. I've actually only been doing this for about four years. Before that, I was an archivist for 10 years, and prior to that I worked in ethnography and music. Currently, I have a small consulting business called The Current, where I help companies with their knowledge management challenges. I've also been working with Amazon for the past few months.

Alison: I'm Alison Jones, and I imagine I'm here because from 2022 to 2024, I worked with Atlassian where I built the Atlassian Research Library for their research team. This library contained all their research content and made it discoverable, which made a significant difference to both the team and Atlassian's ability to leverage research insights. This was my first role in tech and my first role in research—I come from a librarian background, which is exactly why I was able to accomplish what I did at Atlassian. Before working there, I worked in government and law, and I'm about to return to the law library sector.

Julian: You're both here because when I go online to learn about repositories or knowledge management, you are the two voices I listen to most. You're my go-to figures when it comes to knowledge management. So let's dive in: why is knowledge management so central to research practices and organizations today?

The Core of Knowledge Management in Research

Alison: Research is fundamentally in the business of knowledge. Without proper management of that knowledge, it becomes much harder for research teams and entire organizations to understand what they know or what they're working toward. If we can't access our previous work, if we don't know where to store new insights, if we can't share findings easily, then our work becomes exponentially more difficult. Knowledge management is vital because knowledge is the core of what research teams produce.

Emily: I completely agree. I think it's also because of the explosion of information and tooling—researchers love tools, and while they're great, they also scatter knowledge. The first thing I heard when I entered knowledge management in UX was "we can't find anything." We can't find our past research. That was the number one complaint I heard, and I still hear it, though now it's evolved more into "we can't synthesize knowledge."

If you read anything in the knowledge management field, these professionals usually sit in IT and manage things like intranets or customer service content. It's a core business function. But research teams also need this knowledge management expertise outside of that traditional IT context.

Why Repositories Fail: Common Pitfalls

Julian: I love repositories and believe a well-built, well-maintained repository creates tremendous value. But playing devil's advocate here—many researchers build repositories that eventually fail. They don't get engagement, and insights go there to die. What are they doing wrong?

Emily: Let me start with some context from our library backgrounds. Both Alison and I have extensive experience working in libraries, and we've seen this problem before. In library science, a "repository" actually means something different—it's a physical place where items are housed, like "this rare book is housed at the Yale Music Library." We'd walk into these repositories and always see backlogs of things needing to be cataloged or processed. It was funny to us that UX was using "repository" because we knew the challenges—librarians spend their entire careers trying to get people to visit these places and pushing content out from them.

Alison: Getting to your question about why repositories fail—speaking plainly and perhaps controversially as someone who's moved through UX—I think repositories often fail because research teams don't take them seriously enough. They think repositories are easy to create, something that can be done on the side as a spare-time project. You can certainly start that way, but if you continue treating it as a side job without developing expertise and scaling properly, it won't thrive.

People often say librarians and archivists are "luxuries." But we're only luxuries if you don't take knowledge management seriously. We wouldn't say researchers are luxuries because research shouldn't be done by non-researchers.

The other major issue is that teams focus heavily on building the repository and getting it running. When I delivered the first iteration of the Atlassian library in March 2023—about 14 months after joining—there was relief from management. But I told them, "Now we have the hard job: getting people to engage with it." That's actually much harder than building the thing itself.

Emily: Exactly. I don't actually build libraries—I start with the people work first. We're user researchers, right? You don't build something before knowing what you need. You have to understand exactly what's required first. I've been in situations where companies said "we don't have time for research," and I respond that you better make time.

Another crucial point: researchers aren't incentivized to look back at what they've done. There's no time for reflection, no incentive for retrospection. This is completely different from being an archivist, where you're constantly looking back and analyzing the past.

In my first role, I actually told the company they didn't need a traditional repository. Their biggest problem was that insights weren't being used or seen. They needed a delivery tool built on knowledge management principles—you still need to get your house in order and understand where things are, because without that, there's no learning. You cannot learn if you can't examine what you've done or what others are doing.

The Value of Looking Back

Alison: When we built the Atlassian Research Library, researchers initially thought it was mainly for external stakeholders. While it was widely used outside the research team, the biggest advantage was enabling researchers to look back at their work. When someone asked "what do we know about X?" they could quickly find everything related to that topic.

Suddenly, desk research and secondary research became feasible. What used to be a two-week exercise could be completed in minutes or, for complex topics, within an hour or the same day. This made an enormous difference in our ability to respond to urgent stakeholder requests, and the insights we gained exceeded my expectations.

Julian: That's exactly what I'd expect. There are really two parts to the repository journey. What Alison accomplished with her library expertise created a gold mine for researchers—a place to synthesize past work and grow their understanding. But where many fail is expecting this same repository to also handle delivery to stakeholders, because that's a completely different user base with different needs, wants, and expectations. It's challenging to build a single repository that serves everyone effectively.

Alison: We actually had about 10% of Atlassian using the repository by the time I left in December 2024—less than two years after launch. But I agree that the next step would have been taking repository content and making it available where people already work, rather than requiring them to visit the repository. We had some automated feeds delivering targeted research updates, but expanding that delivery mechanism would have been ideal.

Learning from Libraries: Real-World Insights

Emily: I want to share a library story that illustrates these challenges. At the Yale Music Library, we faced a problem: the School of Music students weren't using the library, which was located on valuable central campus real estate. The administration wanted to move it to a remote location, so we needed to prove its value.

I conducted an ethnographic study—peer-to-peer interviews where music students interviewed each other about their daily routines. We discovered they didn't come during the day because they were busy with classes and rehearsals. They came evenings and weekends, wanting to print music and access specific services, but our hours and services didn't match their needs.

So we changed everything: extended hours, hired evening reference librarians, reorganized the physical space, and—crucially—went to the School of Music daily. Librarians would sit outside rehearsals and classes, starting conversations and conducting outreach, meeting students where they were.

It was successful, but it was enormous work. This is what librarians spend our days doing, which is why we understand so well why repositories might fail if they're not actively maintained and promoted.

Practical Advice for Getting Started

Julian: We know the ideal scenario is having someone work full-time on knowledge management, but research teams often struggle with headcount. What advice would you give researchers who can only dedicate, say, 40% of their capacity to building something like this?

Alison: It's crucial to start somewhere, even if you can't build the perfect repository immediately. Start as soon as possible—don't wait until you have a substantial body of research. Use simple tools that are already available across your company.

Consider tools like SharePoint lists, Confluence databases, Notion, Airtable, or even Google Sheets or Excel. Start with basic fields: title, author, date, and what the research is broadly about. When I arrived at Atlassian, they had a simple Confluence list of all their research going back to 2019—just title, author, and date. That was a fantastic foundation.

I recommend concentrating on recording and describing research consistently, but not necessarily gathering everything into one location. Think of it like a library catalog that tells you where to find the actual book. Create a catalog that tells people what research exists and where to find it, rather than spending time collecting everything into one unfindable pile.

My three key tips: start simple, use tools everyone can access, and focus on recording and describing rather than gathering.

Emily: Alison's approach is so informed by library science principles. I call them knowledge management principles, though they come directly from library science.

First is curation. Researchers curate constantly—deciding what to include in reports, what makes a good study versus a bad one. Be aware of this process and be absolutely ruthless about curation.

Second is access. Everything librarians and archivists do serves access. The tooling will change, organizational structures will shift, you'll need to migrate systems—but if you don't have solid knowledge management principles, you'll create ongoing headaches.

Third is description, which Alison emphasized. This is why I created a course on Maven—there are so many people who need this foundational knowledge.

I also want to caution about data storage. Librarians and archivists would never put data in proprietary tools where you might lose access. Companies change tools constantly—they might eliminate Slack or switch platforms, and you lose all that data. Consider having both an internal repository for secure data storage and an external repository for sharing curated content with stakeholders.

Finally, think about capturing tacit knowledge—the experiential knowledge that exists in researchers' minds but isn't recorded anywhere. I spoke with a researcher about a benchmarking study who mentioned, "Nobody uses this product out of the box." When I asked if that was in his report, he said no—he assumed everyone knew. That's essential context that needs to be captured somewhere.

The Importance of Reflection and Documentation

Julian: That's such an important point. Researchers often assume people understand things the same way they do, but researchers are constantly synthesizing different sources and information types to reach conclusions. That mental synthesis needs to be shared and documented.

Emily: Exactly. We need to be reflexive in our practice. I often ask researchers, "What do you think you're going to find? Write that down"—because that's usually where bias lives. Or "How do you think that study went?" They'll tell me the story of the study, but that story isn't captured anywhere, and it's incredibly valuable context.

Julian: Even informal documentation helps—a one-pager distilling everything and writing down those insights that exist outside the formal report or presentation.

Emily: I worked with a manager who would conduct team debriefs after every study, asking those same reflective questions and recording the responses. That's a simple practice any team can implement.

Listen to the full episode on Spotify

The Challenge of Being First

As a first researcher, you face unique challenges. Unlike joining an established research team with documented processes and clear workflows, you're entering an environment where research activities may be scattered, informal, or non-existent. Your first priority isn't to start conducting research—it's to understand what's already happening and identify where the pain points lie.

A Simple Mapping Exercise

One effective approach to tackle this challenge is a mapping exercise that helps you visualize the current state of research activities across your organization. This exercise serves multiple purposes: it reveals existing research processes, uncovers operational pain points, and helps you understand the research maturity of different teams.

Setting Up the Framework

The exercise uses a simple two-axis graph:

Vertical Axis (Y-axis): Satisfaction level

• Top: Happy/Satisfied (😊)

• Middle: Neutral (flotation line)

• Bottom: Sad/Frustrated (😢)

Horizontal Axis (X-axis): Process timeline (steps in chronological order)

How It Works

The process is straightforward but revealing:

Identify Research Activities: Start by cataloging research or research-like activities happening across the organization. This could include user interviews, usability testing, surveys, or any form of user feedback collection.

Break Down Into Steps: For each activity, ask stakeholders to describe every step in their process as granularly as possible. Each step becomes a separate "ticket" or data point.

Map the Experience: For each step, ask stakeholders to rate their experience:

• How difficult was this step?

• What challenges did they encounter?

• How satisfied were they with the outcome?

Plot the Results: Place each step on the graph based on where it falls in the timeline (x-axis) and how the stakeholder felt about it (y-axis).

What You'll Discover

This exercise typically reveals several types of steps:

Easy Wins (high on satisfaction): Steps that work well and don't need immediate attention. These might include activities like "scheduling interviews" if the company has good calendar systems.

Major Pain Points (low on satisfaction): Steps that consistently frustrate people. Common examples include:

• Recruiting participants

• Managing incentives

• Synthesizing and sharing findings

• Getting stakeholder buy-in for research

Neutral Zones: Steps that work adequately but might benefit from optimization over time.

Gathering Multiple Perspectives

The real power of this exercise comes from collecting input from various stakeholders across different teams. Each person's map will look different, reflecting their unique challenges and experiences. Some might struggle with participant recruitment while others find data analysis most challenging.

Workshop vs. Individual Sessions

You have flexibility in how you conduct this mapping:

Workshop Format: Bring multiple stakeholders together for a collaborative session. This works well when you want to build alignment and shared understanding across teams.

Individual Sessions: Conduct one-on-one conversations with stakeholders. This approach often works better when you're new to the organization, as it feels less formal and allows for more candid discussions.

Hybrid Approach: Combine both methods—start with individual conversations to understand each perspective, then bring groups together to discuss common patterns.

When Research Doesn't Exist

What if you join a company where no formal research has been conducted? Don't worry—the exercise still works. Simply reverse the approach:

1. Map Your Ideal Process: Outline what a typical research process should look like in your context

2. Assess Anticipated Challenges: Ask stakeholders to identify which steps they think would be most challenging given the company's current resources, tools, and constraints

3. Identify Preparation Needs: Focus on what needs to be in place before you can successfully execute each step

Beyond Pain Points: Additional Insights

While identifying operational pain points is the primary goal, this mapping exercise reveals much more:

Tool Landscape: What research tools are currently being used? What tools have teams considered but not implemented?

Skill Assessment: What's the research literacy level across different teams? Who has experience with specific methodologies?

Research Culture: How do different teams view research? What are their expectations and assumptions?

Resource Constraints: Where do budget, time, or personnel limitations create the biggest barriers?

Turning Insights Into Action

Once you've completed the mapping across multiple stakeholders, look for patterns:

• Consistent Pain Points: Issues that appear across multiple teams or activities

• Quick Wins: High-impact, low-effort improvements you can implement immediately

• Systemic Issues: Deeper organizational challenges that require longer-term solutions

• Knowledge Gaps: Areas where training or documentation could make a significant difference

The Foundation for Your Research Operations Roadmap

This mapping exercise provides the foundation for building your research operations roadmap. Instead of guessing what the organization needs, you have data-driven insights about where to focus your efforts.

The steps that consistently rank low in satisfaction become your priority list. The neutral steps become opportunities for optimization. The high-satisfaction steps become examples of what's working well that you can potentially replicate in other areas.

Making Research More Accessible

Ultimately, this exercise isn't just about understanding current pain points—it's about making research effective efficient for everyone in your organization.

By systematically identifying and addressing the barriers that prevent teams from conducting research, you're building the foundation for a research-driven culture.

Whether you're joining as a first researcher or working as a consultant with organizations new to research, this mapping exercise provides a clear, collaborative way to understand the current state and chart a path forward.

The goal is simple: help teams conduct more research by removing the obstacles that stand in their way.

Remember, the most sophisticated research methods in the world won't matter if your teams can't execute them effectively. Start with understanding the landscape, identify where people struggle, and build from there. Your research operations roadmap—and your impact as a researcher—will be much stronger as a result.

Many researchers struggle with intake forms because they try to implement solutions that worked in their previous organizations without considering whether those solutions fit their current environment. This is especially common among researchers transitioning from large companies to smaller ones, or junior researchers trying to replicate practices they've heard about elsewhere.

Listen to the full episode on Spotify

What Is a Research Intake Form?

A research intake form serves as a centralized inbox for research requests from stakeholders across an organization. When someone needs help with a project, wants research conducted, has questions to explore, or needs assistance with user recruitment, they submit their request through this structured form.

These forms typically include fields such as:

• What decision are you trying to inform?

• What is your goal or objective?

• What specific questions do you have?

• What's your team name?

• What's the priority level for your team?

• What's the expected business impact?

• Can you share any supporting documents?

The form can be customized for your specific organizational needs, but these represent the standard elements most researchers include.

When Research Intake Forms Work Well

High Volume of Requests

The most obvious use case for intake forms is when you're overwhelmed with requests. If stakeholders are constantly pinging you on Slack, sending emails, or stopping by your desk asking for help, an intake form adds beneficial friction to the process. This prevents you from going crazy trying to juggle everything that comes your way.

Filtering and Prioritization

Intake forms act as natural filters for requests. Often, when someone casually asks, "Can you do this piece of work?" or "Can you help me with this?", the request hasn't been thoroughly thought through. By requiring requesters to work through structured questions, many realize their request isn't actually a priority or that they already have the information they need.

The form forces people to consider: Is this truly urgent? What specific question am I trying to answer? Is this decision important enough to warrant research resources? This reflection often leads to more thoughtful, well-defined requests.

Managing Ad Hoc Requests

When you have your quarterly roadmap planned but keep getting derailed by mid-quarter project changes, new ideas, or urgent requests, an intake form helps you pump the brakes. It creates a structured way to evaluate whether these pop-up requests are worth disrupting your planned work.

Centralized Team Structure

If you're part of a centralized research team that serves as an internal agency providing research services to different product teams or departments, intake forms help centralize all requests. This is particularly useful since you might work with different teams each quarter, and having a centralized system ensures nothing falls through the cracks.

When Research Intake Forms Don't Add Value

Embedded Team Context

If you're embedded within a product team, intake forms are largely unnecessary. You're already part of the weekly or daily rituals, you know what's happening, and you're collaborating directly with product managers and designers to craft your own roadmap. Adding bureaucracy to this organic process doesn't make sense since you're already on top of what you'll be working on, and any ad hoc requests come from your immediate team.

Low Research Maturity Organizations

In organizations where people don't yet understand how to interact with research, don't see its value, or haven't integrated research into their processes, intake forms can be counterproductive. In these contexts, you're unlikely to receive many requests anyway.

Instead of creating a passive system that waits for requests, you need to be proactive. Hunt down projects, knock on doors, and ask: "What about this project? Should we conduct research for this? Do you need help with that?" You need to actively demonstrate research value rather than waiting for people to come to you.

Early-Stage Startup Context

In fast-moving startup environments, formal intake processes often feel too slow and bureaucratic. The pace of change and need for rapid iteration typically call for more flexible, direct collaboration approaches.

A Hybrid Approach

The choice between using intake forms or not isn't always black and white. Many researchers, particularly those who are the first or only researcher in an organization, find success with a hybrid approach.

Consider implementing intake forms for requests coming from teams outside the product organization—marketing, branding, customer success, or other departments. These teams can go through the formal intake process with structured requirements and documentation.

Meanwhile, work more organically with your core product teams or product trios. Discuss priorities and roadmap items directly as they evolve, giving product teams the flexibility they need while maintaining structure for external requests.

This approach provides bureaucratic protection from external demands while preserving the collaborative relationship with your primary stakeholders.

The Importance of Tracking

Regardless of whether you use a formal intake form, tracking all research requests is crucial. Every request should eventually become a ticket in your project management system—whether that's Jira, Monday, Notion, or any other tool.

This tracking serves several important purposes:

Resource Planning: Having data on request volume helps make the case for additional resources, whether that's headcount, tooling, or budget.

Capacity Communication: When you can show stakeholders that you received 55 requests but only had capacity to tackle 15, it creates a clear picture of demand versus capacity.

Future Planning: Historical data helps you predict busy periods and plan accordingly.

Organizational Impact: Demonstrating the volume and variety of research requests helps showcase the value research brings to the organization.

If you don't use a formal intake form, make sure to convert Slack messages, emails, and hallway conversations into tracked items. This documentation will be invaluable for future conversations about resources and team growth.

Making the Right Choice

The decision to implement a research intake form should be based on your specific organizational context, not on what worked elsewhere. Consider your team structure, organizational maturity around research, request volume, and the nature of your stakeholder relationships.

Remember that tools and processes should serve your work, not the other way around. Whether you choose a formal intake system, an organic approach, or something in between, the goal is to enable great research that drives meaningful business decisions.

The best system is the one that helps you manage your workload effectively while maintaining strong relationships with your stakeholders and delivering valuable insights to your organization.

If you’d rather read, here’s the full interview:

Julian: First of all, congratulations on your book "Research at Scale." I think many people who have been working in the research space were thinking, "Finally, we have a book about this!" How did the book come about?

Kate: I signed the contract with Rosenfeld to write the book in 2020. Louis approached me and asked if I would consider writing down what I knew about research operations, given my work building the community around it. I write to understand what I know, but also to evolve what I know.

By 2022, I had a decent draft, but the industry had changed dramatically. We went from a thriving industry where people were flying all over the world, teams growing wildly, to a completely different scenario. I realized I had written a book built on the sentiment that we were growing and scaling, but we had just learned serious lessons about where we weren't actually hitting the mark of scaling value.

So in 2022, I rewrote half of the book—literally six of the 12 chapters—to dig into what I had observed over 13 years in the space and how corporations run. I had to answer two vital questions: What does scaling research even mean? Because "scale" is thrown around everywhere, but we're not producing cars or cookies, we're producing knowledge. And secondly, how do we deliver value as research into an organization?

These two big questions occupied my mind obsessively for a couple of years before the book was finally published in September last year.

Julian: That's a great story—rewriting half the book is a lot of work!

Kate: It was a lot of work, but I think it was worth it. The earlier version was sort of a recipe for how to deliver research operations, but research cannot just be finders or creators of knowledge anymore. We must be builders.

My belief is that to deliver value into organizations, we've got to become specific about how we operate. What has happened is that because of the rise of research operations, research leaders now think that operations is a headcount—you get your headcount, and then that headcount sorts everything out for you. But operations is really a verb. It's a way of being, a way of living, and therefore a way of interacting with the world around you.

How you operate will determine how much value you deliver into the organization and therefore how robust you'll be when the next economic crash comes. Operations should be rooted in the building of your finders and builders—deciding what tools and resources you need at this point in time to meet the needs of the organization.

Julian: Operations is not just a headcount, but an action. This show is about first researchers or small research teams, and at some point, we need to think about the infrastructure we build and wear that operations hat. Something you probably hear a lot is that operations is for large teams, not small companies or teams. When should researchers or research teams start thinking about building infrastructure or practices that are scalable?

Kate: You are operating, whether you're a big team or a small team, and whether you've decided how you operate or not. If you don't decide how you're operating, then you're likely operating inefficiently or not delivering value to the right places in the organization.

I love to use a restaurant analogy: You'll get a dinky little café on the corner with maybe three tables outside. They will have systems in place that enable them to operate as a small café. They still need to be organized—ensuring regular coffee supplies, working refrigerators, finances sorted—to operate within laws and keep customers happy.

At the other end, you'll have a massive 150-seat restaurant with a head chef, large kitchen, alcohol licenses, supply chains, and huge walk-in refrigerators. They're working at a completely different scale, but both still need to think about how they operate. They still need supply chains, just at different levels.

Julian: I love the analogy! You use a lot of analogies throughout your book, which is a great way to get points across.

Going back to what you mentioned earlier about the changing landscape, why is it important for businesses to think about systems that scale in the current research landscape, especially when teams are downscaling?

Kate: That's one of the best questions any podcast interview has asked me! It's assumed that all systems should be scalable, but it takes a lot of work and usually money to build and maintain a scalable system. Sometimes it's not necessary.

You might be a five-person research team that will only ever look after a certain amount of people or recruit a certain number of participants, with no foreseeable headcount increase. Your reality might be making the most of what you've got, not building a massive system that's going to grow exponentially. Not everything has to be scalable.

But even if you're small and likely to stay small, you might look at how to scale the value you deliver to the organization, not necessarily the size of your team or the number of reports. That's a nuance on scaling that's often forgotten.

For example, with a team of five serving five stakeholders, you might look at how to take what they're producing and consolidate that knowledge—perhaps by getting a headcount for a librarian or finding a way to structure content so it appeals to higher management or even founders and CEOs. The team stays mostly the same, but the value you're delivering is scaled, and the longevity of your assets is extended—a fantastic opportunity for a small team.

Julian: This brings me to an interesting concept from your book: cost center versus value center. How would you connect this to the strategies you'd recommend to keep moving in the value center direction?

Kate: A smart research leader has a strategic mindset and looks into the organization to determine priorities. If you don't have more funding but might be able to squeeze out a headcount with the right pitch, you could build a strong library—not just a house for knowledge, but an interconnected communication platform to get knowledge moving around the organization in the right ways for the right people.

The skilled research strategist is looking for primary opportunities where, with a little leverage, they can make a mountain move. Another example is democratization. You might not be able to democratize for everyone, but you could work specifically with designers to build systems enabling them to do the research they need.

My belief is that the research team of the future needs to be an octopus. You can't just have one arm because you'll go around in circles. You need multiple arms where you're delivering democratization, knowledge across the organization, advocating for customer insights, and so on.

Julian: From finders to octopus—we could do a season on building octopuses!

A common question I get is about researchers wearing different hats—researcher by day and builder by night. How can they pitch to the rest of the organization that working on operational topics is important and worth the investment?

Kate: I always believe in show, don't tell. Operations and strategy both have massive baggage and mysticism around them. Operations is not a noun—the headcount you hire in operations roles are there to bring life to the way you've chosen to be. Strategy is often confused with visionary ideas of the future, but it's really your practical plan for bringing your vision to life.

If operations is just seen as "someone's going to sort out all the plumbing behind the scenes," that's valuable—I call that "keep the lights on." But no one appreciates well-run operations because you shouldn't notice it until it goes off.

To remedy that and show what excellent operations looks like, get a baseline of "keep the lights on" operations, then find a spike or vertical orientation where you can show value to senior leadership. Look for what your organization is paying extra attention to right now.

For example, if the CEO says increasing daytime television viewership is a priority, you could set up a recruiting panel specifically for that audience, create a rich area in your library for daytime television insights, and formulate specific ways to distribute that content. This creates a vertical "spike" that people notice, rather than just the horizontal operations no one sees.

When they see this new value, they can start to understand what operations can deliver, and that's when you can get funding you wouldn't have otherwise.

Julian: That's fantastic! Speaking of spikes, in your book you talk about the eight elements of Research Ops and then connect this with the Research Ops Venn diagram. Can you elaborate on that?

Kate: Research operations efforts are wildly misunderstood and underestimated. People might say, "I'm going to build a panel by procuring this tool," without planning for all the other necessary elements. Then later they realize they need to address privacy and ethics, create onboarding processes, set up thank-you gifts, and so on.

The Venn diagram takes the eight elements and overlays them because wherever you start on the journey, you're going to encounter all of the other elements. It helps you think holistically and upfront about all the work, thinking, and design needed to deliver this as an operable part of your organization, rather than just a siloed tool that's ticked off the to-do list but doesn't actually function or add value.

Julian: For those who are starting to build a practice or working on the infrastructure of their practice, what three tips would you give them?

Kate: First, before diving in, stop and think. Take a Buddhist moment and consider what you really want to achieve, what resources you have, and what needs consideration. Come up with a plan and strategy: Why am I doing this now? For whom? How much is necessary? When does it need to launch? What's the goal? This might take a day or two weeks, but it's worth it because you'll save wasted time later.

Second, once you have that plan, step back again and work out how this machine will operate. Everything you do will have various moving parts to make it operable and sustainable. Design the system—what kind of researchers? What kind of research? Who's involved? What mix of ingredients does this recipe need?

Third, build sequentially and patiently. Find low-hanging fruit to show quick value, but don't get stuck there because that "high carbohydrate diet" isn't sustainable. Look for the "bone marrow"—the deep nourishing stuff that might take a year or two to deliver but provides long-term value.

Julian: I love it! I usually say "plant the seeds and water the sprouts"—another analogy we can use.

Want to know more about Kate Towsey, her book and masterclasses? Make sure to visit her website, where you can find all the details!

Till next time!

Does it always make sense? How can you use it to your advantage? What are the risks it implies? Find answers to this and more in this amazing episode!

You can also find this episode on Spotify:

Audio or video not your thing? Here’s a full transcript of the conversation

Julian: Welcome to Finders to Builders. Today we're discussing research democratization with two amazing guests. Let's start with introductions.

Tina: I'm Tina, an independent researcher and innovation consultant. I've been in this business for more than 10 years working for client and Finance Science, now also in sports.

Kathleen: I'm Kathleen, an independent research consultant, coach, and the founder of Grown Connect - a community for research leaders where we talk about our challenges and help each other move forward and grow. I've been leading researchers and research teams for almost 20 years but am now independent. I've experimented a lot with research democratization and know about the good and the bad. I'm happy to talk about it openly so we can discuss what works and what doesn't.

Julian: This is a topic on which people have strong opinions. If you go online, you'll find many articles for democratization, some against, and voices that have changed their minds over time. It's interesting to address this in 2025 because there have been many changes since this first appeared a couple of years ago. How do you see democratization evolving in the following years? How do you see it merging with how researchers approach their work nowadays?

Kathleen: That's a good question. We've been going through these waves. For a while, research democratization was seen as something dangerous that you shouldn't touch. Now, with more smaller teams that need to grow and scale, they're looking at it again as a way to increase capacity or have more impact. At the same time, there's increased demand from product teams - many product people are interested in doing more research. They've been reading Teresa Torres's book, and I always say I'm not sure if you should love or hate her, but there's definitely an increase in demand from that side, which makes people consider democratization more.

Tina: Maybe to connect to what you just said - it was a big thing. I have a presentation on the topic where I point out that researchers are like these fluffy, very nice people, teletubbies. And then I have another slide where teletubbies become zombies. This happens when it comes to two topics: personas and democratization, where we love to fight and go into flame wars on the internet. I feel like it's not anymore about whether we should democratize, but how we do it well.

Julian: Absolutely. That's a key distinction. Sometimes I had the perception that democratization was framed as something that would end our jobs as researchers. But in other cases, I saw this as a recipe for success. Could you share your perspective on cases where democratization is a good idea and cases where it's not? Or if this is something we need to embrace, how can we embrace it in different types of organizations?

Kathleen: From my experience, it depends a lot on where you're at in your organization and where you're at personally. Sometimes when research maturity is low and you have a small team, it's very hard to get buy-in to do more research or hire more researchers and do the strategic work you want to do.

If you're interested in democratization, it can be a way to get people to understand research more. It can open up understanding, increase maturity, and from that increase demand and maybe get buy-in for extra headcount.

But as a solo researcher, that has a flip side. If there's a lot of demand for research and democratization, the only thing you'll be doing is teaching other people how to do research and handling research ops. Then you don't have time to do the impactful research you want to be doing, because those first rounds of research aren't the great, impactful research that should be happening.

So you can get stuck. If you're not interested in teaching others and helping them grow their skills, you'll feel really trapped. You might want to be doing different types of research, but when you start democratization, you typically begin with usability testing - the easy, entry-level stuff for quick wins.

It depends on whether you're interested in teaching others and scaling the practice. If you are, it's wonderful. If not, you should push back and say "I should be doing highly strategic, impactful research. That's where I'll get my wins and increase maturity."

Wherever you are, it's both about the organizational needs and maturity as well as what you want as a researcher. If there are people on the team interested in doing this, it's a wonderful opportunity to learn. I always find that when I'm sharing my practice and teaching others, I really love my job. But I've also had people on my team who I forced to work with product teams to teach them research, and after some point they said "this is not what I want my job to be." I've had a person resign from my team saying they wanted to do different types of research. I felt crushed - I lost a really good researcher because I made her do things that didn't sit well with her.

Julian: That's a really good point. This goes both ways because from the researcher side, maybe you force a researcher to become a trainer or someone who explains research. But also on the other hand, you have a lot of people who maybe don't want to participate. Maybe designers say, "Why are you taking me out of Figma? I don't want to leave my Figma world." Or product managers say, "I don't have time to talk to customers." So it goes both ways. People often argue "Karen from accounting cannot do research" - but I've never had any Karen from accounting saying she wants to talk to customers.

Kathleen: I actually have had Karen from accounting do research. It was really fun - they enjoyed it a lot.

Julian: But more as a one-off, not as a forever thing?

Tina: Just to connect to this - Kathleen mentioned maturity several times, which is important, but there's also the willingness to do research. It's not really connected to maturity because some people, even when maturity is low, are like "I want to do research" or "I want to get in touch with it."

What comes to mind is that with democratization, sometimes there's a peak and then it goes lower because people realize "Oh wow, it's so complex and it's so much work. Let's go back to the researcher to do it." This is maybe what comes to mind when you were speaking about that colleague leaving - sometimes we frame it as training, but it's more like internal consultancy. It's not just training that we give, it's "how do we approach the problem together" and we can lead people in it.

But I get the frustration. If you want to focus on the craft, you want to focus on the craft. And that brings me to another point - we all give each other recipes and it's great inspiration, but in the end, what is freedom in research? Personal and professional freedom in research is something I'm trying to understand for myself. I think everybody has to do it their own way. If you're a good trainer, train people. If you're good in research ops because you're structured, drive democratization through research ops.

It's also about the match between your approach and the people you're working with. As you said, there's Karen from accounting who might be more interested than the product manager. You can adjust your democratization attempts to their needs. That's what I find super interesting - sometimes it drives me nuts, of course, but it's interesting to work with different people and have different levels of democratization in organizations.

But I have a question for you both: where was your triggering point where you thought "I have to start thinking about democratization"? What was the situation where you realized "I have to do something about this"?

Kathleen: For me, it's always been about seeing people in product teams who don't understand their users and trying to get them involved in research to help them understand and get firsthand contact. The easy entry point is having them observe sessions, but I've always strived to get them in the room with me, asking questions and shaking hands with users.

It makes so much more impact on them personally. As soon as you talk to someone firsthand, you have a story to take with you, which can skew your idea of what is true tremendously. If you have one firsthand experience that hits you in the heart, then all of a sudden you as a product manager carry the torch for that one user you've spoken to - which can go horribly wrong, obviously. We've all seen that: "Why do they keep banging on about this one person they spoke to?"

I think that's where it originated for me. It started casually, but when I had a team of about 10 researchers working with 40+ product teams, we could never be embedded in all of them, but we wanted all of them to start doing research or have access to research and insights. That's when I started thinking about scale - this was about 8-9 years ago.

The mistake I made was saying "We'll divide all the product teams among these researchers, and every researcher has to help coach, train, and guide their product teams." That was a mistake - I don't think I should have forced it on people.

I think I could have eventually evolved it into creating a program, seeing which product teams were interested, and making it more voluntary. I could have ensured that researchers on my team who were really interested in teaching and training would build that program, freeing up time for other researchers to do other things. I've experimented with this and learned the hard way.

Julian: When you put it that way, maybe in some cases, if the team is large enough, that would make the case for hiring a research ops person so that all that training falls to them instead of researchers.

In my case, when you're the only researcher or first researcher, you're pretty much outnumbered. There are two situations: either there's a large appetite for research across the organization that you can't handle alone, so you need to leverage your skills with the capacity you have; or you're in a less research-hungry context, and you need to generate an appetite for research. By getting people involved and creating this appetite, the more people start learning and the better they become, the more appetite for research grows overall.

As the first researcher, you want to generate more appetite - you want people to get interested and hungry for more research. It's like the supermarket where you offer a bit of cheese to try, and then people can buy it. When there's little interest in research, this can set everything in motion. They experience it firsthand and then start valuing it much more.

This brings me to my next question for Tina: democratization is interpreted differently by different people. Some think it means everybody can research, others think only some people can research, and for others, it means bringing people along the research journey. How do you align people on what democratization means in your context?

Tina: If we're looking for a definition, I don't have one. Democratization, like most things in life for me, is a spectrum. It's connected to the research personality and to the freedom of the researcher - where do you feel strongest? You have to use your strongest suit; if you're not using it, you'll probably burn out quickly.

One thing that came to mind when you were asking this question: in companies, let's not talk about "democratization." People don't understand it. I made that mistake - I said "We're going to democratize" and the buzzword became so strong that people put their own definitions on it rather than letting research define what it really means.

On the other hand, democratization means different things with different clients. I'm working with a meteorological company for almost a year and a half, and it's a very different story than I've had with bigger, more structured but less mature companies where fewer people were into research. It very much depends on the spectrum of people and their willingness.

I know it's a somewhat cloudy answer...

Julian: It's a researcher's answer, right?

Tina: It's not only a research answer but a critical mind answer. And that's maybe one of the main messages about democratization - it doesn't have one recipe. As Kathleen mentioned, it's different for different types of organizations, teams, and maturity levels. You can't just copy-paste an approach.

Kathleen: I sometimes refer to it as "socialization of research" to get rid of the "democratization" word because it's so toxic by now and brings up anxiety for many people. Sometimes it's more about socialization or boosting empathy for research and insights - including people in your practice. It doesn't have to be called democratization.

And there's no one recipe. It can be asking interested people to do it with you. But it will never work if it's forced. We know if it's forced on the researcher, it doesn't work. If it's forced on designers, PMs, or product teams, that also creates resistance. That part is just hard, and I have forced it on people, but then it takes a long time, and I'm not sure if it's worth the effort.

I remember one PM who kept asking "This research objective you keep talking about, why is that important?" It took six months of constantly forcing her to think of the research objective. After half a year, she would be the one in a room saying "Okay guys, we need to have a research objective first." But it's a long time.

It made me think I needed to use different words - I couldn't keep using that kind of language because it's off-putting. I've had a designer say "Oh, you're so academic." I realized I shouldn't use "research objective" - it should be "What do you want to learn?" or "What do you need from this research?" You need different languages to make it accessible and feel like "Yes, I can do it" rather than it being a blocker because it seems academic or foreign.

Julian: This is a very interesting topic that could be a full episode - how researchers communicate outside the research team or across the company. We could discuss vocabulary and how to be less "researchy" when talking with the rest of the company.

I'm also interested in how democratization changes according to industry or company type. B2B versus B2C - what's your experience with these different contexts?

Tina: For me, in B2B, especially with complex topics (and I have the luxury of working with complex topics), democratization is essential. You don't just allow people - you need the product manager and specialist to be involved in the research because of the complexity.

For example, with meteorology, I tell respondents "Talk to me like I'm an idiot because the more I study meteorology, the less I understand it." I need the people who've been working in the company for 20 years - they're almost meteorologists themselves. We prepare scenarios together, analyze together, and I need them there.

We had to set rules like not interrupting me or the respondent - "Don't explain the software" - and they'd say "I know I made this mistake, but I had such a strong urge to interrupt." We have a rule that during the last 15 minutes, even if I forget because I'm in the flow of conversation, they have every right to interrupt and ask their specific questions - questions I wouldn't be able to ask in the next 10 years in meteorology.

The same goes for finance and investments. If we're talking to people with high financial literacy, I need a product manager from investments or debts to ask specific questions. Again, emphasizing the B2B aspect - if it's software for other companies, I need them there to ask specific questions and even understand what was just said.

Julian: This is fantastic because some people think that as researchers, we should know it all and have context and knowledge to interview about anything. But bringing people along the journey extends the reach of your research. If you have someone super technical, they can take you that extra mile by asking questions you wouldn't think of because they have years of specific knowledge. We as researchers get to learn about different industries, which is a cool part of the job, but we can't go as deep as someone who's specialized in meteorology, for example. What are your thoughts on this, Kathleen?

Kathleen: I think sometimes it's not so much about industry but how long people have been working in a company that makes them think "We know our users. I've been doing this for 10-15 years." It's such a wake-up call for them to actually talk to customers they don't think are their customers.

I worked in a media company where we did this radical experiment - we invited the whole media house (journalists, editors, product and tech people, receptionists, everyone) to do research with us for a full week. I had different research events planned each day - guerrilla testing in the mall, group discussions, one-on-one interviews with different types of users.

One of the target groups was younger news avoiders - people who don't connect with what the newspaper writes about or get information from social media rather than reading news. It was such an eye-opener for staff to talk to them in person and realize "This is the challenge we have ahead of us. I might know the 60-year-old news subscriber who still wants a paper newspaper, but I don't know the people who should be consuming our product in the future."

That experiment involved about 40 people doing research for the first time. They got scripts and guidance, but the quality of the work was terrible. Just imagine getting handwritten notes from 40 different people and trying to extract insights - it was horrendous. The researchers on that project probably still hate me for it.

But what happened throughout the organization was breaking down silos. Those in sales, content, product, and tech had to work together to conduct interviews. There was socialization inside the organization with people they hadn't worked with before, and they shared this experience of interviewing users they didn't know. There was this buzz around the whole media house - "I talked to this person, what have you done?" - and suddenly the research was generating conversation.

It changed a lot in terms of knowing to ask for research early rather than using it just for validation at the end. They realized you can get so much from these conversations and that research should happen more often and earlier. But they also concluded "And you're so good at this, you should be doing it." So it wasn't "We can do research ourselves" - even the journalists, who thought "This is easy, I'm good at asking questions," were stunned by how much skill it takes. They realized "This is really hard."

Julian: I'm going to play devil's advocate now. Kathleen, you just mentioned that these people were doing research and the results were terrible. Some might ask: should we actually allow people who might produce low-quality results anywhere near research? Could that be harmful to the product or dangerous? Are there contexts where we shouldn't consider democratization? Is it something we need to build? What are your thoughts?

Kathleen: If you're working with products and services where lives are at stake, that's maybe where I draw the line. But other than that, every person is making product decisions several times a day. They might make those decisions based on what they think and feel, what they think they know, or the bad research they have. But hearing different voices and experiences still enriches your gut feeling, putting some extra "microbes in the gut" that make it function differently.

I don't see how that's bad, honestly. I've never experienced it to be totally bad. I've seen worse things happening from "I talked to a friend and I think we should do this" or conversations people have at home or with potential investors. I've seen worse product decisions made there than from democratized research.

Tina: I think there's a difference between the event where you had this research day with people generating data for the first time, and democratization as a process. The event lets them taste research and see its beauty and what it can bring them. Then democratization becomes a process of collaboration - forcing collaboration on people and forcing us to collaborate with them.

Subscribe now

It's progressive - step by step, they see how to get good quality results. What I love is when they ask those "Would you be using that?" questions in the last few minutes, and I allow it. Then I go back to the respondent and ask "When was the last time you did this?" and they say "Never." Those are the moments where I can say "See, this is why this question seems like a great idea, but it's actually a bad idea."

Then they understand the difference and what it means to come up with bad results because people claim they'll use something in the future that they've never used before. They connect the dots very quickly.

Kathleen: Yes, but this is the difference, right? You're doing a lot of guidance and coaching while keeping quality control in the loop. People are allowed to make mistakes, but then you wrap it up and make it a learning experience.

When bad research happens or leading questions are asked, people are quite often aware of it. They see the difference between them doing an interview and you doing an interview, and they learn by watching you.

I've never experienced people thinking "With a couple of training sessions, I can do this - I don't need you. Just get participants to come here and I'll do whatever I want." People really love the guidance and support and training to get better at it.

Julian: Throughout this conversation, I think the three of us are aligned on the virtuous cycle created when this process starts - everyone starts talking about research and understanding how it's done. Let's try to tackle the opposing voice. What would you say to people who argue "We are researchers and we are training people, so we are then obsolete"? How do you see this affecting potential researcher job openings in the future?

Kathleen: I have to add a caveat. I think I had great success experimenting with democratization while working in the Nordics, and both you and I are based in Europe. I think the climate here is very different from other places - the most resistance I've seen is more from America, for example.

I think education costs a lot more there, and job security is a lot less - this comes into play. I was working in a culture with a lot of focus on collaboration, continuous learning, openness about sharing your practice, freedom to do your work the way you want, and no strict performance indicators or bonus schemes. Everyone's very relaxed and open to doing things outside their job description.

I think if you've invested tons in your education and are paying off massive student loans, maybe you're less inclined to share your practice with the threat that your job might be on the line if others feel confident they can do it without you.

At some point, everything seemed fine, and then someone came to me and said "I lost my job after I trained the designers how to do research." So I realized my experience is different in different places, cultures, and types of organizations.

Tina: Nothing to add on that - the privilege we have here is real. On the other side, I think in this conversation we've shown that with democratization, you can actually demonstrate how complex the work is. You can sell it through democratization because people with even a little self-reflection will see "I would have to learn a lot." I haven't met many arrogant people telling me "Your job is easy" after experiencing it themselves.

Going back to freedom - make yourself crisp, as we say in my language. Make yourself a good cookie that people want to chew on.

Julian: I love that one.

Tina: It's hard to explain when I'm translating from a Slavic language, but hopefully some people will understand.

Kathleen: All the Slovaks in the audience!

Julian: Make yourself crisp. I love it. To add to something Kathleen said - it's a different dynamic here in Europe in both senses. I understand the education aspect, and also teams tend to be larger in other parts of the world. In North America, companies might have 15-20 researchers, but in Europe that's not as common. Even large companies here often have small research teams, and hiring happens much slower.

Even if you're successful as a researcher, getting the second or third hire can take a year and a half. In some European countries, notice periods are three or four months. So imagine you're hiring - it's already a slow process taking 2-3 months, and then they say "Great, in four months I'll leave my job and join your company." That's eight months of waiting for a researcher. The pace here is completely different than in other parts of the world.

In some places it might be "Hey, more researchers! We'll bring in six researchers in two months." That doesn't happen in Europe. So if you don't democratize, you probably drown if there's appetite for research in your company. You have a million requests and need to do this out of survival.

This brings me to my last question. I always ask guests for three tips for researchers, but let's twist it and ask for three tips for setting guidelines for democratization at a company. What would you advise people who are thinking "I need to set this up or create a program"?

Tina: I'm definitely not a patient person, but I'm very persistent. That brings me to persistently mapping the organization and their hunger for research, and picking ambassadors. Going back to our conversation about extremes - it's neither no democratization or total democratization. We live in extreme times where everything is either this or that, but it's still a spectrum. Finding your spot and how you want to do it is definitely a good recipe.

And the last one comes from personal experience: don't democratize because you're close to burnout. That's exactly when you should be doing something else - maybe setting priorities or democratizing but not running studies. That's maybe the third piece of advice on what you're not supposed to do.

Kathleen: I feel your pain. Yes, but it happens, right? Especially for solo researchers when it's too much, democratization seems like the solution. That can be stressful.

My advice would be to start with people who are keen. Start small - don't make it big. Start with interested people. Second, find peers who are also thinking about doing it or have been doing it, and exchange ideas with them. Geek out with another researcher like we're doing here. It's worth talking about it a lot - how have you done it? What has worked? What hasn't? See if you can exchange templates or training material so we don't all have to create everything ourselves.

Last but not least, be kind to yourself. Don't push too much. It takes time. I've told researchers on my team "Oh yeah, just do this and then it will free up time for us to do other things." But it doesn't work that way - it takes a year or two to do it well. It's not "This quarter we'll do this and then after that, we'll have more time." So be kind to yourself and stay true to yourself.

Julian: Thank you both for the tips and for this beautiful conversation. I had a great time and hope you did too. Thanks everyone for tuning in. You can find us at finderstobuilders.com, on Spotify, Apple Podcasts, and YouTube. Stay tuned and see you next time.

You can find Tina on Linkedin or hosting UX Research Geeks and you can find Kathleen also on Linkedin or check out her Research Retreats.

Check out the full episode on Spotify:

Meet Our Guests

Nikki: "I'm Nikki. I am a user researcher and a founder. I guess now two as well. I do content and coaching on one side of my business or as its own business. And then my other business is still user research consultancy. So I do lots of research, but I'm only allowed to do research in Jersey, which is the channel islands. Yeah, it's a fun time having a visa. So I do a lot of research with financial institutions that don't really know what FinTech is. And on the side of things, I'm obsessed with Stephen King and write horror fiction that I one day hope will become a New York Times bestseller. That's like my dream. So like research, yeah, cool, but horror, really cool. That's me."

Chris: "I'm Chris, I run my creator business, UX Playbook and Backlog. UX Playbook is my attempt at UX education through playbooks, courses, and coaching. And Backlog is something different, it's my endeavor to help content creators build a better business. I'm a self-taught designer. I've been designing for 10 years and left the corporate world probably about four years ago. And stumbling into content creation and stuff like that during that time. So this is all an exploration in terms of business and content and what that means really to be solo."

Getting Started with Content Creation

Julian: How did you start or come up with the idea of creating content? Did you just one day say, "Okay, I'll start writing about this"?

Nikki: "Mine is slightly more selfish than 'Oh my gosh, I'd love to enrich the community' and more along the lines of 'Wow, these people keep asking me the same things.' Therefore, what I'm going to do is create articles. I'm a writer, so it was very natural to be writing as my platform. I was just going to create articles based on the frequently asked questions in user research. That's literally how I got into creating more longer-form content. Then I realized people don't just naturally discover my articles. So I decided instead of hoping that somebody would stumble upon my well-written beautiful article on recruitment and screener surveys, I decided to start posting on LinkedIn to share that content to a wider platform."

Chris: "My story is a little bit different. I left a really toxic job, like super mega toxic job. It was just before the pandemic was closing down the world. I couldn't leave Thailand at the time. So I was like, 'What do I do with all this time trapped in a country?' Well, everybody was trapped somewhere. So I decided to play around with video and that was my first medium of content creation. The first video I made was actually about me quitting my job. I didn't really lean in initially. It was more of a creative endeavor. When UX Playbook organically grew on its own, I was winding down a startup that I was co-founder of because we basically couldn't find product-market fit. My partner pushed me to create content to push this to a wider audience. We've been going for over a thousand days now in terms of publishing every single day."

Minimum Requirements to Get Started

Julian: What's the minimum requirement to get started for folks who are just beginning?

Chris: "You can just get started with your phone. No mic, no teleprompter, no lights. Literally your phone by a window would be fine. That's actually what I did. What I started was very different. I didn't have a microphone and I bought a cheap action camera for like a hundred bucks. No tripod, nothing. It was just me sat in front of a camera. I did a bunch of shots. I put the camera somewhere, I walk past and then picked up the camera later. No scripting. I just watched a lot of videos before I made my first video because I wanted a certain feel. I've always been fascinated with Casey Neistat's style. So that's the exact video style that I tried to emulate. Totally honest, you don't need anything. You just need your phone and everybody's got one."

Nikki: "I love that you reference something outside of our space as inspiration because it can sometimes be hard and you can get stuck a bit in a vacuum of 'Who are the other UX people that do this?' I've often found that the best inspiration comes from things that are vastly different from what we're doing. Like I'm obsessed with the podcast Heavyweight. Finding that inspiration from outside is so important. It doesn't have to be within our industries. And yeah, you don't need everything to get started. Just start."

Starting with Writing

Julian: How do you start with writing? Because a lot of people, including myself, get pretty intimidated by the blank page.

Nikki: "If writing isn't your jam, you don't have to write to create content, there's just so many ways to create it. But if you're wanting to push yourself into writing, the first thing that I would say is think about the one actionable thing you want somebody to take away from what you are writing. I utilize that goal of what I want somebody to take away to inform the rest of the article. And I never give myself a word limit, which is sometimes not good because I'm like, 'Great, I have like 5,000 words, that's way too many!' But I always start with that end goal in mind. So that way you're not starting with a blank page. You write the goal down, write what you want somebody to take away at the end of it. I don't outline anymore, but I just go ahead and say, 'Okay, how do I build up to that outcome?'"

Chris asked Nikki: "Do you spend more time writing or more time editing? And has that changed over time?"

Nikki: "Writing. I write final drafts. But keep in mind that I have been writing since I was like seven. I've been writing nonfiction user research-based content since 2017. I used to edit a lot more. What I tell people is overwrite and then cut rather than trying to write the perfect thing and then add stuff to it. But now I usually write a final take. Sometimes I'll go back and tweak here and there. But I try and aim for first draft is the last draft."

Benefits of Content Creation for Your Career

Julian: For people who may not be considering pursuing this as a side hustle or their main hustle, how can creating content affect someone's career? How can they benefit from creating content if they keep their 9-to-5 job?

Chris: "They can absolutely benefit from it. Not saying that everybody should, but I think you can. One of the ways that people will find you is if you shout loud, and how do you shout loud on the internet? You just share your work. You don't have to say 'I'm this thought leader, I could teach you X, Y, Z.' You could just be like, 'Look, this is what I learned' or 'Here's the thing I did' or 'Here's a mistake I made.' It can absolutely benefit your career - job opportunities, connecting with other designers in the world, or you could spin up your own little product if you wanted to. I think there are more positives than negatives, but we should probably speak about the negatives in terms of things like being hooked on vanity metrics. For folks interested in trying it, I'd say just create blindly. We started creating every single day just to get the reps in - it was nothing about quality, it was all quantity, because I didn't know what I didn't know."

Nikki: "I want to echo the sentiment that it's great if you would like to create content, but just get really clear on why you're doing it and what the point is. Creating content can actually help you a lot with organizing your thoughts and helping you understand things more deeply and from different perspectives. And I think that is a hugely beneficial thing to have for your career because as people in UX, that's a huge part of our jobs - to understand different perspectives and bring different perspectives and question ourselves. But the second that I started creating things for other purposes, like for selling things, for making money, for getting engagement, for getting leads... the second I go too far over that line, my posts suck. You can't let it impact you, but it's scary when it's your job and a means to making money. But if it's just something you're wanting to try, do it blindly. Do it for the fun that it is."

Julian: "I completely agree with what you both said. You need to bet on the long game. If you start creating content, whether it's LinkedIn, Instagram, YouTube, whatever, it's not going to be an overnight success. If you write once a week, twice a week, five times a week, you don't need to think about this week, next week, or next month. You need to think about next year. Is this shaping my way of thinking? I create predominantly on LinkedIn. The format helps me distill my ideas in a very short format. It's all about the long game. Maybe your first couple of posts suck, but after one year of creating content, when you go back to it, you've cringed a bit. Most people online are not creating content but consuming content. So if you just get started, you would be part of the 1-2% of people putting stuff out there."

The Dark Side of Content Creation

Julian: What are the horror stories regarding content creation? What are the biggest challenges when creating content for you?

Nikki: "I've been stuck in a horrible place with creating content. When I get into creating content for the wrong reasons - I don't want to say like the wrong reasons, because I'm a business, so I have to sell things. But when I'm not really focused on sharing information or what my audience needs or empathizing with my audience, that's when I hit those horror stories of just being really stuck and not knowing how to create or what to create and being frustrated. Then of course all my posts are flopping, which just churns into that horrible cycle of 'This is the worst. I'm the worst. What am I even doing with my life?'"

Chris: "I think one for me, which a lot of people get, is where people are just toxic. They don't know how to have a productive debate and they're just assholes. They never think about how it affects the other person reading. I don't phase by that stuff anymore, but I can imagine if you're just starting out and someone comes across your content and they're just yelling at you, you could feel really bad. Social media doesn't really have nuance. You want to take a stand because that makes your point even more poignant, but folks don't get that. But the joke is actually on them because of the algorithm. That's why I don't get bothered about it anymore."

Julian: "Speaking of feeling the algorithm and negativity, sometimes you see this content on different platforms around fear-mongering or spreading negativity. That also feeds the algorithm. Sometimes you have to polarize if your ideas are strong enough, but you will face people creating content just to bash other people or to bash other ideas. That's pretty much the toxic side of all this."

Chris: "There's also unprecedented plagiarism. It's everywhere. I actually found someone early in my journey on LinkedIn and I was like, 'Wait, that's exactly what I wrote!' I messaged this person and it got taken down. The work that you put in can get taken credit for, and it could do better in terms of vanity metrics than what you do."

Nikki: "I've had people take my free work, copy it, and put it up for sale. But it's so hard, especially with things like the internet and LinkedIn. Everybody's going to take it. And unfortunately, some people will just take it as their own rather than crediting you. That used to really kill me. But now I'm always like, 'You know what? At the end of the day, this is what the internet is.' There needs to be some letting go of the control that we have because it's just impossible to control the internet and social media."

Charging for Content and Services

Julian: Nikki, why didn't you charge for your content in the first place?

Nikki: "Probably because I am a mix of things - as a female, I feel inherently like I should not be doing this. It's something that I talk to a lot of people about. There can be a lot of shaming around charging, like I see a lot of shaming around charging for mentorship. My mentorship looks really different than somebody who's on a mentorship platform having one-off calls. My mentorship means I'm in your back pocket. I respond to you immediately for six months straight and give you unlimited constant feedback on anything and everything you ask or submit. So the amount of time that I put into each mentee is hundreds of hours. I think I had a really hard time, and I still do, with figuring out what I should charge for, what I should leave as more open and free, and what that balance is."

Chris: "Maybe it's also a symptom of just internet culture in general. You pay for your internet line or phone bill, but then most of the time, especially with social media, it's all free. Only recently we've noticed that they're selling our data. But I also think there's a huge shift. Maybe it's just because I'm in a creator bubble, but everybody has something they're offering. And if you find it valuable, it's usually behind a paywall."

Julian: "You get that a lot - 'Why are you charging for mentorship while others are not?' But there are a lot of trade-offs there. Every hour I dedicate is not just the hour that we are together, but also all the hours that I give you support, or I talk to you, or I answer your emails. And then all the time that I'm investing there, I'm not investing elsewhere - in my business, my family, hobbies, or partner. The opportunity cost is that when you start thinking in those terms, you charge because you consider this as value for potentially someone's career. There's also the flip side that if you pay, you're also showing that you have skin in the game and you're committed."

Nikki: "Something else that I found interesting is like people have a hard time seeing me as a business or a service. I find it really hard for people to see me as like, 'Hey, I actually need to make a living from the things that I'm charging for. Like, literally, this is my job.' And I think people can sometimes have a hard time seeing that, maybe also with the fact that a lot of stuff is available for free.”

Three Tips for Those Starting With Content Creation

Julian: What are three tips you would give people who are starting out with content creation, whether it's video, LinkedIn, Instagram, writing, or whatever?

Chris:

1. "Get as many reps as possible. You're going to suck at first, so you have to push past the suck. If you can fight through it, it gets more fun because if you're good at something, that usually builds momentum."

2. "Imitate. Copy first, because that's usually easier, or take heavy inspiration, whether it's a certain video style, editing style, composition, or way a story is told. You can reverse engineer how they did it."

3. "Choose a medium that seems fun. Writing is probably the lowest barrier to entry because you don't need much gear. With video, you still need a phone, but with writing, hopefully you have pen and paper."

Nikki:

1. "Get really clear on your goals and why you are creating content. What's your brand voice? You don't have to have a brand, but what is the voice that you want to put out?"

2. "Don't be scared to use AI to get started. I use AI as a thought partner quite a lot to help me understand different topics or ideas. I ask ChatGPT what I'm missing from something or what perspectives I'm missing."

3. "Stay super authentic to what feels the best to you. If something is not feeling good, you don't have to continue doing it. If you want to change medium completely, do that. Be flexible with the things that feel the best for you."

I added my three tips:

1. "Be careful with AI. You don't want to end up with content with capital letters all over the place and rocket emojis."

2. "Ignore the naysayers. If they don't like your stuff, they can unfollow you, they can block you, they can go and cry on their own."

3. "Get started. The best time to get started was one year ago, two years ago. The second best time is now. If this is what you want to do, regardless of the medium you choose, just simply get started. Don't think too much about it, and you will get better on the way. Think of the long game."

Meltem: I'm a Barcelona-based UX career coach. I work with UX professionals across disciplines to help them figure out their next step and strategize for their careers. I also offer webinars, courses, workshops, and trainings for organizations, but coaching has been central to what I've been doing over the last year.

Marvin: I've been in the design industry for a bit over 20 years now. I also work with UX professionals, mostly mid-career professionals, and help them get unstuck and find out what the next path could be and how to get there.

What Does It Mean to Get "Stuck"?

Marvin: One of the first things that comes to mind is that in UX, we are taught to work in a certain way and have all these methods and tools at our disposal. Then we hit reality and find out that real-life jobs don't look as we were taught, which becomes difficult and frustrating. Many senior people reach a level where they don't know what's next. They have all the tools and methods, but they still aren't making the impact they want or are no longer happy with what they're doing.

We work together to uncover what really motivates them around their job and UX design, how they got there, what their strengths are, and how to reconnect that to their next step, whether it's leadership or transitioning to a different role entirely. It's really based on who you are as an individual, what your strengths and skills are, and what motivates you.

Meltem: I agree with everything Marvin said. What's fascinating is that being stuck can look and feel different than what we might expect. It's not always someone experiencing burnout or getting laid off. I have clients who are very well-paid at the best organizations in their country—everything looks great on paper—but they feel stuck. They don't know their next steps, don't wake up motivated, and don't feel like they're growing.

Similar to Marvin's approach, I encourage folks to look inward first. Understand yourself better: Where does that feeling come from? Which strengths do you identify with? What are your passion areas? We get unstuck by setting goals where we have leverage and control—internal things we can track and trace. Maybe the results won't be exactly what we want right away, but we move toward them.

Marvin: It's not always about getting more salary or external validation. For some clients, the answer has been to not move up further but rather to specialize or find a narrower path than the broad "I can do everything in UX" approach. The beauty of the UX field is that it's so broad that you can find something truly yours that makes you happy. We spend so much time at work, it would be a shame to waste the privilege of being creative and having a fulfilling job by staying stuck.

Let's divide these people who are stuck into different buckets. Let's start with people who are elsewhere, doing something else. What advice would you give these people considering a job in the industry nowadays?

Meltem: For career transitioners who might not necessarily be juniors in their field but are taking a leap of faith to do something new in UX, the first consideration is not to start from zero. Really understand what transferable skills you have and what you've learned in your previous work that would be a good match for UX.

UX is a field that's interdisciplinary in nature, which is why we're all attracted to it. It can welcome people from different walks of life, different training, and different professional experiences. So it's about understanding what you've done, what results you've delivered, and what value you created in previous roles that could make you a better designer or researcher. This would be the first exercise I'd encourage people to do to get unstuck, then identify opportunities and go for them.

Marvin: Transferable skills are top priority for me as well. The second thing I'd say to all people stepping into design, whether transitioning or starting new after university: give yourself time. Right now, we have this trend of people rushing through UX education, doing a bootcamp for a few months, and then wanting to be ready for the market.

As we said earlier, UX is a really broad field, and to do it well takes time. You have to learn and study the methods and skills needed to be an impactful designer. I wish for people to give themselves more time to discover where they excel rather than just jumping in. I understand bills need to be paid, but don't stop learning just because you've completed a course.

To people who are already in UX and want to step up, grow, get a promotion, or get better at what they do. What advice would you give those people who are maybe two or three years in?

Marvin: My advice is twofold. First, investigate why you want to move forward and what you're seeking. If you're not clear on that, it's hard to find something satisfactory. If it's about money and you just need a promotion for a raise, that's totally valid—but it's different than if you want more impact, influence, or a more strategic conceptual role.

Second, invest in yourself. Obviously, as a career coach, I recommend working with someone who can help you reflect on what you're already good at and build a path for you. But also—and this is critical—work with your manager. If you're looking for a promotion, your manager can be a partner in getting you there. They're not just evaluating and saying yes or no; they can help you succeed. Good managers will be happy about you reaching out and asking how to improve and get promoted because it makes their lives easier. They're being paid for you to succeed, so working with them creates a win-win situation.

Meltem: I agree with everything Marvin said. When looking at my experiences with clients in this bucket, I see those who don't want to get stuck in their projects anymore. They want broader influence in the business.

Along with understanding what you're seeking and collaborating with your manager, networking is crucial. Understand what people within your organization care about, how they articulate their goals and initiatives, and what they need to achieve success. If you as a UX professional can find ways to help others advance, this will lift you up. You'll become someone who isn't just tasked with certain projects but can have a broader influence on OKRs, strategic vision, and much more. This is how you become more senior and strategic—by seeing beyond individual projects.

Marvin: Without visibility in an organization, moving up the career ladder as a designer can be tough. You won't get there just by hunkering down, doing the hard work, and bringing great design results, because they won't be seen as much in organizations that aren't as mature in UX as we'd wish.

So, as Meltem said, reach out to colleagues, find out how their goals are set up, and use your unique skills to help them achieve their goals. This helps you stand out. When promotion rounds come up, everyone will know your name, making it easier for your manager to make a case for you.

Meltem: Do that networking diagonally—not just with your manager, but also with people at your manager's level (vertically) as well as horizontally.

I'd like to address those people who maybe want to move but don't know exactly where. They feel stuck but don't have any direction. What would your advice be for those people?

Marvin: If you're stuck and don't know where to go, first look at why you're feeling stuck—what's wrong or missing. From there, you can get a good idea of what you're actually looking for.

For more experienced people who have been in the field for more than five or seven years, there's often a lack of growth. They're still in a senior role, maybe doing the same things they were doing two or three years ago, and it feels like they're not moving forward anymore. It might be time to explore: Is the manager's path right for me, or should I further specialize as an individual contributor?

For that, you really have to find out if management is something you want to do. It's a different job, and the skills that got you to a senior position as a designer might not be enough for management because it's a different beast. Once you have that clear, you can decide what you want to be doing.

Also, investigate if you want to move up at all, or if it's just external pressure. Sometimes you reach a point where you're not learning anymore. Throughout my career, I was always the most senior designer on the team, constantly pushing forward and learning. At some point, I felt like there was nothing left to do. My wife suggested, "Why don't you turn around and, instead of being the learner, become more of a teacher?" That can be very fulfilling and a great way of being impactful while growing professionally, even if you're not growing your craft as much anymore.

Meltem: I work with many people in this segment, including some with 30+ years of UX experience. There are unique challenges for this group because they often have existential crises: "I have maybe 10 more years left in my career. I want to spend it meaningfully. I'm not satisfied with repeating what I've done in another organization. I don't want one more raise or one more senior title. I want to do something meaningful that resonates with my inner essence."

For these clients, we really need to go on a journey to figure out: Is it about the sector? The kind of people you work with? How you'll get to work? The degree of innovation you'll experience? Maybe it's about teaching, maybe it's not about the craft, or maybe it's something that looks further and different from that. It's important to be authentic to yourself as you go through that exploration because we don't know what the answer will be.

What advice would you give to people who became managers because they thought that was the growth they were after, but now they're having second thoughts?

Meltem: One thing we sometimes forget is that anytime you're thinking of a career change within an organization—whether becoming a manager or switching your scope—it has to perfectly align with the needs of your current business.

In the case of that example, if you're a manager who realizes that track isn't your thing and you want to become an individual contributor or staff-level, you need to make sure your organization is one where that title isn't reduced to something that practically doesn't exist. Ask the honest question: Is there space for the kind of change I'm seeking, or is there buy-in to create that space? If not, you've got to be honest with yourself and explore what other organizations could be right for you to grow in a meaningful way. It has to be a win for both you and the organization, or it won't work.

Marvin: When you said "moving backwards," it triggered me a little, maybe because I've done it myself. I don't necessarily think the idea of moving upwards into managerial positions is truly correct, especially for UX professionals.

Why not go back into an individual contributor role? Obviously, check your finances to make sure it aligns with what your family or partner needs, but it doesn't have to be a demotion or something bad. Maybe it's just the right thing for you. Management is a different job than design.

I found myself having a seat at the table, discussing things that, when I started in design, I actually wanted to get away from. I didn't want to just have business meetings and talk strategy in a room full of alphas—I wanted to engage with designers. The more I moved up, the less I got to do that. That can be fine for some people, but you have to be aware of what you're doing. Choosing a path more in line with who you want to be isn't a step backwards at all.

Many people think that to grow, they need to be better at hard skills. Designers need to get better at Figma, learn design systems, or for researchers, it's about methods and more complex stuff. Is that it? Are hard skills the thing that will unlock your growth or career moving forward, or is there more to it?

Meltem: This topic is close to our hearts, both Marvin's and mine, because we work with a lot of senior professionals where hard skills are either already there or can be learned. Remember, hard skills today, working in tech for any UX professional, aren't solidified—new tools and ways of working require you to keep updating your hard skills.

But regardless, I genuinely doubt, especially in the age of AI where everything is accessible to learn and improvise, that hard skills alone will make the difference. It's really the ability to deploy your soft skills alongside those hard skills that matters. This is where you can network, craft your storytelling so people understand what you stand for and where you can drive impact, connect with people the right way, make intentional choices, and articulate the driving forces behind your initiatives.

Communication comes to mind as a key soft skill, but there are many more leadership skills—like how to build a team around an initiative or help people identify with and rally around the same goal. These are vital. I don't see anyone getting a job purely for hard skills because everyone can get them or claim to have them. It's the soft skills that really make you a brand and distinguish you as a UX professional.

Marvin: It's not 100% clear where we draw the line between hard and soft skills. If you're a manager or a very senior UX professional, collaboration, communication, and mentorship might be part of your hard skillset—things you absolutely must do for your craft.

What Meltem said about not relying just on the methods and tools of UX is very true. To get a promotion, you often need to be visible, which comes with negotiation, collaboration, aligning yourself with others' goals, having empathy for team members (not just users), and really being part of the whole organization, not just a designer in an organization.

That said, I want to make a case for the craftsperson. Many designers don't want growth that moves them into management or more strategic positions—they just want to be really good at their craft. This can be highly impactful. Think of design systems: if you're a great design systems designer or manager and you've mastered that part of the craft, you can greatly impact organizations by influencing how everything is built. So narrowing down on craft or hard skills can be a good growth path, though it's not the same as moving up the traditional career ladder. Both ways are fine—one requires more collaboration, negotiation, and business skills, while the other focuses on deepening expertise.

How can people stand out in the current UX market? How do they showcase their value as professionals?

Meltem: These two questions are intertwined because you should be pursuing what distinguishes you—not just anything. This is what coaching helps with. It's not about what everybody in your team pursues or what seems like the logical next step (like moving from senior product designer to manager).

You need to understand what makes you unique—something that both speaks to you, that you love, and where you have talent that's harder for others to match. You want to keep learning about it, and it has business value. This win-win—something you love that also has business value—is your unique talent. Make sure you pursue opportunities where this unique talent shines through, not just anything. That's what would make a difference for people pursuing their dreams.

Marvin: I often come across designers on the job hunt who are applying to everything they see just to increase their chances. What this actually does is wear them down and stress them out, because with more applications come more rejections. If you're not targeting roles that align with who you are, your chances of early rejection are even higher.

I work with clients to find out what they bring to the table and what roles really align, then devise a matching strategy. Application processes are matching processes. Companies aren't just looking for the "best designer"—they're looking for the best designer for their unique situation, organization, and team needs. The clearer you are on what you provide and how you may match their needs—and the more you have this pitch ready—the easier it is for stressed-out HR people to make that connection and see that you may be interesting.

There's another benefit: if you're clear about who you are, your strengths, and what you bring to the table, you'll be more confident in interviews. It becomes less about passing their test and more about talking about yourself, your strengths, and seeing how that matches what they need. It's a totally different conversation. I do have to admit, it can be hard to uncover what you're good at—and that's where our coaching work comes in.

Meltem: Absolutely, because so many people have impostor syndrome or have faced numerous rejections. They come saying, "I'm not really good at anything"—but that's never true. There's always something. And it's not about competition with others; it's about looking within yourself, your experience, the results you've created, the value you've brought, and what you really care about. Then you can speak authentically in interviews.

What advice would you give people who may be overlooking networking? How can it help them grow, how can they benefit from it?

Meltem: One thing I want people to remember is to be specific. When networking outside your organization, your first impression is usually the last impression. Be very clear about who you are, what you care about, what you want to build, and your background. This makes you easily memorable and understandable, so people think of you for future opportunities.

If you're posting on social media, have a clear niche that shows what you care about and what value you bring, instead of just having casual conversations without anything tangible coming from them. Networking has to come from a place where you already know what you stand for, what your strengths are, and what you care about. You need to know yourself so you can express it when networking.

Marvin: Many people think of networking as weird, salesy, transactional behavior. There's a flaw in this thinking. Don't approach people asking to "pick their brain" or requesting an hour of their time just to learn something—everyone's busy. Instead, offer yourself in service. Provide value to someone and then get value in exchange. So in a way, it is transactional, but you need to provide first.

Beyond that, it's about being part of the design community—engaging with peers, learning from them, and telling your stories, because there's always someone who can learn from your perspective. When I was reluctant to post or write because I didn't feel I had a voice or anything new to share, my coach told me, "They may not have seen it from your perspective. Your perspective is just as valuable." There's always someone coming after you, and sometimes it's important to be a representative of a certain group so people can relate and identify with that.

Another benefit of networking: it's healing to see you're not alone in your struggles. UX work can be hard and stressful when you're trying to fight for user-centered approaches in your organization. When you engage with peers, you discover that everyone has these fights and struggles, no matter how long they've been in the industry. Sharing different perspectives and tricks can be calming and healing.

Check out the full episode on Spotify or Apple Podcasts:

Jen Blatz is a user experience researcher at BECU, one of the largest credit unions in the United States. She is also a co-founder of UX Research and Strategy, one of the biggest UX groups in the world. Jen has a YouTube channel called BlatzChatz.

Check out the full episode on Spotify and Apple Podcasts too:

What are the most common challenges people face when managing stakeholder expectations?

Amanda: What I've seen and experienced firsthand is navigating misalignment. That could mean unclear objectives, conflicting priorities, or misunderstanding what research as a discipline can deliver. Another unfortunate perception is that user research is sometimes seen as a nice-to-have rather than a business-critical function, which can lead to stakeholders undervaluing its role.

I like to think about alignment in a strong intake process as a way to counter that. It really starts at the beginning, trying to prioritize and clarify those foundational questions that we're great at asking as researchers—turn those on our stakeholders. What decisions will this research inform? What risks are we trying to mitigate? Making sure everyone's on the same page about those goals and expectations. And if they're not, then you as the researcher have that data and can be strategic in how to bring those people in or speak to them to understand who you're dealing with.

Jen: I'm going to play a little bit off of Amanda and talk about the intake process. There's so much more to that than just filling in a form. One of the challenges I've found with stakeholders is they come to you saying what method they want to do. "I want you to do a survey," or "I want you to do a focus group." Those are my two least favorites!

They bring the method to you. And to Amanda's point, the question she asks—"What are the risks involved in your project?"—I like to ask, "What does success look like? What will you do with this data?" When you ask questions like that, it shoots down the method because they're not going to say the results they want are a completed survey. They're going to tell you what data they want, what they're going to learn.

So one of the most interesting challenges is them bringing that method to you and saying, "Just do this," rather than "This is the answer I am seeking" or "This is the information I am seeking." It's a little bit of education—getting them to think about the outcome of this research, rather than coming to you with a method that they're familiar with.

Who to involve and when: How do you map out or identify stakeholders?

Jen: When I'm joining a project or a company, I like to do a stakeholder map—understanding who is who, what are their roles, what are their responsibilities. And tying a RACI to that: Responsible, Accountable, Consulted, Informed, making sure that I start to get a feel for the political landscape.

When you're new especially, it's difficult to do on your own. So bring your managers in, bring your teammates in, let them help you navigate those new waters. A good way to do that is to get a stakeholder map, just so you understand who's who in this game.

Amanda: Anytime I'm at a new company or even switch roles at different companies, I see it as an excuse to do this kind of research. And it is—researching your stakeholders is research. There's a method called stakeholder interviews, and that's what I do.

I might not always say, "I want to formally interview you for 45 minutes," but I absolutely have questions in advance that I want to ask folks. Like Jen said, it's brilliant to bring other trusted people, like a manager, into the process. I'll look around an organization or a line of business and say, "Who are the decision-makers here and what do they care about?"

Part of it is social listening—what are people saying on Slack? What are the metrics everyone's talking about? What's the jargon? When we're having company standups or all-hands meetings, what's being shared there in terms of language that I can start to replicate in my own research studies?

Then for the actual interviews, I'll schedule time with everyone. I don't care how senior you are—I've often interviewed C-suites of 5,000-person companies. If it feels important to understand their perspective on a particular product or on research in general, I am not shy about putting time on their calendar and being really clear about what I want to learn. One of those top questions is, "What's your relationship to research? How have you worked with research? How do you want to work with research?" You get so much data that way.

This is also amazing to do when people join your company. Maybe you've been at a company for a while, but then there's a new VP of Engineering—I am the first on their calendar. "Hey, welcome to the company! I'm the researcher around here. Let me chat with you." Again, asking "What's your relationship to research? How do you want to be involved?" So many of those folks become research champions because you get to onboard them to the company.

How do you keep people involved throughout the research process?

Amanda: Going back to what we were talking about earlier, that question of what decisions the research is going to inform—find out who's going to be impacted by those decisions and who has the influence to act on those findings.

I'm at the point in my career where I'm not doing validation research just for the quick checkbox. Who is available to make changes based on our findings? Who's lined up designer time or QA time after this study? I involve those people directly—the people who are going to be working on the next steps of whatever we find. If a project is going to shape a product roadmap, then the PM and the design lead are essential, but the team maybe only needs periodic updates.

I think not just about who those players are that are going to be impacted by the research, but to what degree they should be involved. I treat everyone's time preciously, and I learned that the hard way. I always used to bring engineers into research, and a lot of them loved getting that front-row seat to customers. But then I heard from a few people that it was a huge time suck for engineers to sit in on research interviews and help with synthesis.

I'm very much a collaborative spirit, but that was a hard lesson—maybe there are more strategic touchpoints for certain disciplines. They don't have to be cut out, but maybe they're not attending every session with me.

Jen: This has been something I've struggled with in my career. Most of my roles have been more "go off and research the thing, then come back and show the results." Sometimes stakeholders want to sit in if it's an in-person lab session, but often they're just not interested in participating.

I would love to talk about how you set that precedent at the beginning. Because it can be difficult—if it's not established early, how do you then say, "You're now going to come observe research and help me with analysis"? I've really struggled with that in my work process.

Amanda: This has been the bread and butter of my practice. It's not that it hasn't received any resistance, but my framing was around co-creation. I presented the rapid research approach we took at Lyft—I don't think it's for everyone, but it was born out of me being the only researcher in an office with 80 other people who all didn't know they needed research. Then they became overly excited once they saw research's impact. I was overwhelmed and said, "You're all going to help me."

As an experiential educator, I hosted Lunch and Learns, ran trainings, and created a process for others to be involved. I did it out of necessity so I could survive and accommodate all the requests. But a lovely bonus was that I had introduced this way of co-creating with everyone from individual contributors to VPs. They had all experienced what it was like to engage in research this way.

For projects outside the rapid research program, it gave me permission to make requests: "Before we meet next, I want you to come up with three things..." And people showed up because they got that training. It built not just organizational learning, but showed them how to be a partner to research. Research isn't just putting in a ticket and getting results.

It wasn't a magical experience for everyone, but it worked for the majority of folks. For those it didn't work for, I was still able to engage in conversation and meet them where they were. If it was taking up too much of their time or they weren't sure what a research question was—that was another finding! No one actually knows what a research question is. That was a mid-career mistake of mine, asking "What questions do you want answered? What are your hypotheses?" People don't know how to answer those questions—they don't have our training or experience.

How do you find the right balance between involving stakeholders and working independently?

Jen: It's about experimentation and getting a feel for the team. I'm often in more of a consultant role, so I don't have that deep context and long-term relationship to know that "Bob, my PM, does not want to participate" or is eager to participate. It comes back to learning about your stakeholders and building those relationships.

Also, showing the value is key. Once I was doing interviews for a B2B product, and instead of personas, I created mini-profiles summarizing what each person said—what they value in their workday, their motivations, and pain points. I built it in a digital whiteboard, highlighting key points. I did a couple of interviews every day and drip-fed that information to the team. They loved it: "Wow, we hadn't thought of this pain point!"

If you give that information to designers early on, rather than after completing all interviews, it gets their creative juices flowing. Debriefs are also really helpful—not only to share what you learned, but also to see how different people hear different things. Everyone listens through their own professional lens. Sometimes PMs are listening for confirmation of what they expect to hear. Being there to have those discussions, instead of making conclusions on my own, can change perspectives: "Oh, I hadn't thought about that!"

How do you navigate conflict with stakeholders?

Amanda: I was once pulled into an executive's pet project. A very well-meaning executive got a big idea and sent me a Slack message (partly my fault, because I had conducted a stakeholder interview with them a few months earlier). They wanted me to pull information on a demographic we'd never researched so they could build a new thing—but I didn't know why it was a good idea to build it.

With executives, you can't just schedule a coffee chat—you don't have much of their time. I said, "Great, let me see what I can do for you. Who else should I be chatting with?" I got a few more people to speak to, and I was curious: does this executive have buy-in from their broader team? The answer was no—the team saw this as a waste of time, but the executive was adamant about pushing it forward.

It was gutsy, but I scheduled one-on-one conversations with all the key stakeholders the executive mentioned. I said, "This is on the record, but I want it to be no-holds-barred. We're going to talk about this initiative before we go off and build it, and I want you to tell me exactly what your fears are and what you think this gets us as a company."

I love that we get to do that as researchers. Other disciplines have power dynamics where everyone needs to look good. Research should look good too, but we have permission to be unbiased third parties asking hard questions.

I asked these tough questions and then facilitated a workshop with the executive about what success did and didn't look like for this project. It required delicate moderation and bringing up different perspectives. I went back to everyone I interviewed and said, "This is what I heard and what I'm going to share. Do you have any problems with that?" I was building trust with the executive's team as well.

The workshop ended up being contentious, but everyone knew where they stood from the beginning. The executive was able to see everyone's hesitations and started to play defense—going back to the numbers and figuring out how to make this well-meaning idea make sense.

Jen: I have a fun story about working with developers at a security company. I was the UX team of one, surrounded by engineers. I would talk to our users, hear about pain points, and bring feature requests to the engineers. I had strong relationships with them—they were like my brothers—so we could have playful yet real conversations.

When I'd ask if we could implement a feature, they'd say no. So I'd ask, "What degree of no is this? Is this a 'fuck no, this cannot be done in the universe'? Or is it a 'heck no, it could be done but it's a lot of work'? Or is it 'no, I'm just telling you no because I'm lazy'?"

Then I'd say, "My technical savviness is in the negative—you're going to have to explain to me why it won't work, as if I'm 10 years old." Sometimes, to avoid having to explain it to "dumb Jen," they'd just switch to yes! I learned a lot, but I also made them reveal the truth. You hear that you should know enough code to talk to a developer—I think knowing enough to call out nonsense is really helpful.

How do you handle situations where research doesn't provide clear answers?

Amanda: I think there are two possible paths forward. Most importantly, acknowledge it: "Hey, we wanted to find out this thing. The results were inconclusive." That happens in science, research, A/B tests—it should be okay to say out loud.

The first path is to ask: Should we invest more time to figure this out? Should we try another approach or method? Should we talk to a different target demographic or region?

The second option is to say: "I don't have time or interest in conducting more research. What do we do now?" We as researchers should be equipped to have that conversation with teams. Help them figure out if there's something else we can try or if we're going to go forward with our best guess—and what risks that entails. What are we possibly missing? What's the most catastrophic thing that could happen?

Sometimes that conversation leads to more research. Other times, it means no build—we're not going forward. Maybe it was someone's idea or pilot project, we did a little research, and there isn't time for more, but the risks are too big or there's too much unknown.

Some of my greatest successes were when research led to the conclusion that we should not build something or that we needed to go back to the drawing board. Those kinds of decisions are really important too.

Jen: I'll add that if we all agreed on the research plan, the questions, and what we were trying to learn from the beginning, I'm not going to find additional information as time goes on.

One example: I'll find some data and they'll say, "Oh, did you dig deeper into that?" And I'll respond, "No, I didn't. I didn't realize that was important to you. If you'd sat in on the research with me, you could have asked me to go deeper. Now the opportunity is gone." I'm catty like that! The opportunity is gone, and we can revisit it, but I didn't know that needed to be explored deeply.

How do you prove the value of research?

Jen: I have a "golden ticket" story. I was working at a pet hospital, and the product owner told me, "We're going to development in a couple of days for a mobile app for doctors because doctors go from room to room to check on their pet patients."

When I asked what was going into the app, he listed many features. I asked, "How do you know that's what doctors need?" He said, "Oh, I just know."

I said, "Just give me a couple of hours. I'd like to confirm we're going in the right direction." I had a handful of doctors I could call, so I asked them, "What are the top two things you need the most?" They all said exactly the same things.

Because I did that quick research, we eliminated probably 75-80% of the features. We finished the app six weeks early and way under budget. That's the huge impact research can have in re-scoping a product to be completed faster and cheaper.

Amanda: To sum up Jen's story, my one-liner is: "I collect data to help people make decisions." That's it—insights in, action out.

What are three key tips for first researchers, solo researchers, or researchers in small teams about stakeholder management?

Amanda:

1. Prioritize ruthlessly. You as a solo or small team cannot say yes to every request. Figure out what those high-impact projects are that align with your organization's goals. Sometimes that's doing executional research, like usability tests, to show how research influenced a product directly. It's not always a big, lofty, strategic thing.

2. Create a simple scalable framework. What are repeat processes that you can put into place and then plug and play? This way, you're not developing the process with tight deadlines at the same time as handling all these requests.

3. Build relationships beyond the actual project or product. Think about how to build rapport outside of context-specific projects—grab coffee with a key stakeholder, participate in cross-functional meetings. You want to be seen as a trusted partner rather than just a service provider. People are more likely to collaborate with you when you show up to the