Should PMs Do Research Because Researchers Are Too Slow and Expensive?

“UX Researchers are slow and expensive” are two of the reasons we hear when a PM wants to do research and/or they want a professional Researcher to do less or no research. Let’s do some critical thinking.

Note: this article does not cover when should Researchers and non-Researchers collaborate (or a variety of other things). The rest can be discussed or debated in some other article.?:)

Cost.

Glassdoor says that the average salary for a UX Researcher in the USA is around $99,000 per year (for 2024). The average salary for a Product Manager in the USA (for 2024) is $126,000.

Companies watching how workers and therefore salaries are used might look at this and suggest that if we really wanted to spend less, we put the “cheaper” person on the work.

If all other things were equal, wouldn’t we want the $99K person doing the work versus the $126K person? Companies love to cut costs and save money!

Even if a Researcher were paid more, and they should be, perhaps they’re paid the same as a PM, which would mean that they are not more expensive.

Time.

Time is money. What does your PM need to do in a day or a week? Lots of specialized PM work. How much time will they have for research? Probably not much. They would have to do a little here and there versus being able to devote full-time work to research.

This might be one reason why you hear that a PM just needs to talk to three customers in a week. They might be able to make time for that.

We opened a full-time Researcher job. We compared and interviewed candidates. We made them prove that they are darn good at great research. They do it 30–40 hours a week. They would have more time to do research, and would be able to get a research project done faster than a PM doing it in their spare time or minimal time allocation.

So far, a Researcher is cheaper than a PM and has more time to devote to research.

Time needed to observe and interview participants.

Let’s imagine that we need to make an important decision about our product or direction. We’ll need to observe and/or speak with current and target customers or users.

We care about diversity, equity, inclusion, and accessibility; best research practices indicate that we might need to speak with (let’s say) 30 participants to make sure we get a good mix of people. 30 isn’t wild. My company, Delta CX, does projects like this all the time. We did a project for a famous two-sided marketplace where we met 71 people. That was the best practice number, given how many target audiences they had.

How long would it take for a PM to get feedback from 30 participants? If a PM has made time to talk to three people each week, it would take them 10 weeks to eventually have information, opinions, or feedback from 30 people. We could then analyze all of that data, and see what insights we’ve found.

What if our Knowledge Quadrant shows that we have a lot of open questions, and should conduct 60-minute sessions? How many of these can the PM run in a week, and still stay on top of their PM work? One per day? Two? Probably only a few each week, but let’s imagine they make time to do two research sessions each day.

On my Delta CX teams, we typically do up to four per day (per Researcher). A busy PM might need three or more weeks to meet 30 people (two per day, five days in a week, ten sessions each week). A professional Researcher, whose time is blocked for these sessions, can meet all 30 in 8 business days. Overwork your Researcher a bit (not recommended, but it happens), and they can do it in six days.

So far, a Researcher is cheaper than a PM and has more time to devote to research. A Researcher will do more interviews in a week than a PM is likely to have time for (unless the PM completely blocked their calendar and paused their PM work).

But we want research at the speed a PM does?it.

Let’s say your company insists on methods that might utilize research sparingly or minimally, focusing more on speed than on quality, outputs, or outcomes. We’ll talk to a few people or run a survey, and assume that’s good evidence on which to base strategies, priorities, and decisions.

Most Researchers won’t want to work at that speed or in that environment as it doesn’t match why most of us became Researchers. We want to do things well. We have quality standards. But there are good Researchers who still might want that job.

If a well-qualified Researcher can do the same type of research a PM wants to do, and at the same speed the PM would have done it, why wouldn’t we give this work to the qualified specialist Researcher? They will be cheaper and better at this work. They will apply at least some science and technique, and will reduce or remove bias.

PMs who want to see customers first-hand can observe the research. You don’t have to do someone else’s job to have first-hand knowledge. But PMs also work from second-hand knowledge all the time. They get data from customer support without having answered tickets themselves. They can’t do everybody’s job.

There are ways for cross-functional teammates and stakeholders to be involved in Research without doing the research. Collaboration means we’re working together, but not necessarily doing each other’s job.

Research quality: actionable insights that will drive strategies and decisions.

Few would argue that a PM does higher-quality research than a specialized, experienced professional Researcher. Most of us would agree that the Researcher will do a better job in every phase and task of research.

A research project has many phases including planning, recruiting, sessions, analysis, synthesis, and reporting. Each phase has tasks. Every task can be done deeply badly, really well, or anywhere in between. Research is as good as the weakest link. Do any phase or task poorly, and your whole study could range from flawed to misleading to valueless.

Research has best practices, techniques, methods, and science. Great practitioners have experience, talent, skill, and very often (but not always) an educational foundation in UX, psychology, or something UX-adjacent.

The above February 2024 screenshot is a Lead UX Researcher job at Target in the USA. What this job is looking for includes:

• Seven or more years as a Researcher with a portfolio to prove it.
• Four-year degree in a social science, HCI, or something similar. Preferred but not required.
• Experience with and fluency in a wide variety of research methods, and the ability to choose appropriate ones for what we need to learn.
• Identify key opportunity areas for corporate strategic direction. Yes! Great Researchers are strategic, and can inform, influence, or semi-guide corporate, product, and other strategies.
• Identify and pursue user-centric outcomes.
• Storytelling and project management.
• Mentor Juniors. I noticed it didn’t say anything about teaching PMs to do the work, acting as a “coach,” or democratizing. That’s refreshing.

Many many many Product Managers wouldn’t qualify for this job or even a Junior version of it. Many PMs are not familiar with the best practices or rigor of research. Many of the ones I’ve spoken to weren’t even aware of all of the phases or tasks of a CX/UX research study. PMs rarely have UX, HCI, or social sciences education or backgrounds.

We couldn’t say that a PM is doing research “better” than the qualified Researcher.

With humility, we might have to agree that the average PM is likely to do lower-quality research than a qualified Researcher. The average PM is unlikely to plan or execute the way a Researcher would. The average PM might not spend the time on the phases and tasks that a Research would.

We might get “faster” research but it is likely to be flawed or invalid research. Critical thinkers would question the value of time and money spent on flawed or invalid research.

But by doing fewer phases and tasks, the PM will go faster and save us time and?money!

Perhaps, but consider the risk of lower-quality research. We’ve all seen what happens when a PM or team moves forward with flawed, biased, or incorrect data. We thought we knew our users well, but we didn’t. We thought that focus group showed us the right way. We thought that asking leading questions to random people in coffee shops would be great data to guide important decisions.

• Is the risk of poor strategies, decisions, and products worth whatever time or money we think we saved? Your failures and successes?—?and their short- and long-term costs?—?will answer that.
• If we have to fix it, redo it, or undo it later, did we still save time and money? It’s easy to look only at what research takes (without considering what it produces), and imagine that it’s better to make it as fast and as cheap as possible. But this is the evidence and data that guide strategies, decisions, and product. Working from bad evidence means sprints of Design, Engineering, and more later to fix things.
• More Costs of Poor Quality. Working from bad evidence means the costs of Customer Support utilization. The costs of unhappy customers abandoning, downgrading, or cancelling. The costs of having to figure out what we got wrong, and make fixes, iterations, or new solutions. The costs of poor team morale when people are disempowered and can’t stop others from sometimes obviously-poor decisions.

It’s all about?risk.

There is risk when we do less QA on our code thinking that saves time and money. It will cost us time and money when unhappy users find our bugs, and we have to fix them. Same for research. We can do less, but we increase our risks.

Document risk. Discuss it. If a little more research done by qualified pros could or will save us more than it costs, especially in sprints of Engineering rework, isn’t it worth that time and money?

The Professional/Specialized Researcher will do a better job at a lower?price.

They have more time to devote to the Research work. They are likely to get these sessions done faster than a PM, who might have to spread them out over more time to balance them with their other mission-critical work.

But let’s say we want this even?faster.

Easy. Team up two Researchers working together. This will allow you to get even more high-quality work done each week, sprint, or however you measure time.

This would cost more, but you could pair a more junior Researcher with your Senior Researcher. Maybe the two together cost $175K per year.

Then why hire a Researcher at $99K at all? Why not just hire the cheap Junior? Because they are still relatively new to a role that can take a few years to be good at. They are best paired up with an experienced person. We can tell the difference between someone in the their first job, someone in their first job (but who is partnered with a Senior so they can learn faster), and a Senior. You can throw a Junior Researcher into the deep end, but you might not be happy with their work, efficiency, or other things they are still getting good at.

Couldn’t we pair the PM and the Researcher? I would say no for following reasons:

• A full-time Junior Researcher devotes full-time hours to research. The PM has to fit research in where they can. If we want research to go faster, we need qualified people putting in full-time hours.
• The Junior is paid a lot less than a PM. Every hour that PM spends on research costs more than an hour the Junior spends.
• If we select a strong Junior from our job candidates, they are likely to be more skilled and advanced than the average PM (at research). The Junior still needs research guidance, work reviews, and coaching, but potentially less than the average PM.
• We have therefore hired more skill at a lower price.

Conclusion: What are your standards?

If you are only measuring research by how fast it goes or how cheap it is, then it can always be even faster and cheaper. Zero research is the fastest and the cheapest. Cancel your survey tool, speak to zero customers, don’t research target audiences, and forget satisfaction scoring. That would be fastest and cheapest.

There is a grand canyon of options between that and “academic”-style research that might take years. Research isn’t binary; it’s not a case of “either we let someone else do this fast OR it’s just so slow and expensive.”

And there are other factors that lend to speed, efficiency, and cost. If we skimp on research, that can cost us time and money later when customers are unhappy, downgrading, leaving, complaining, and needing help. It costs us time and money later when we have to figure out what we got right, what we got wrong, and fix our own problems.

The time and costs of research should be seen in the context of the larger project and product. It might take X weeks, but Engineering wants Y weeks. It might cost $Z, but often saves us more than that in lost customers and Engineering rework.

If we look at Research alone, wow, it seems slow and expensive. Put it in the context of a larger project and product, and it can not only make sense but be more than worth it. Shift your perspective towards outputs, outcomes, and quality.

Connect with us or learn more:

• CustomerCentricity.com?—?our website
• youtube.com/@cx-cc ? —?YouTube channel
• patreon.com/cxcc ? —?online community and free mailing list
• Articles on Medium or LinkedIn
• cxcc.to/ckys?—?“Customers Know You Suck,” my recent book on improving customer adoption, satisfaction, and retention