… and says, "I'm looking for actionable insights." The bartender replies, "Well, you're in luck! We serve them straight up, no bias added." (thanks for helping me complete this pun, ChatGPT).
Dear es,
Lately, there has been a lot of (necessary and unnecessary) talk about the collaboration between Product and UX practitioners. Independent but not unrelated, I loved joining a live Q&A session with Nikki Anderson’s User Research Academy members.
During this session, we delved into three key questions (any many more) that are crucial to our work and understanding of UX research and product collaboration.
What things do you see that need to change how product people and user researchers collaborate to make it a more positive experience?
Product Managers must avoid treating user researchers like an outsourced resource, which can come across as condescending. They should acknowledge their skills or insights gaps and how more structured research can help them fill them (compared to “Hey, I need you to do this for me!”).
Vice versa, user researchers should not adopt the attitude "Only we can and should talk to customers because you’re not doing it right.” Even if there are quality gaps in a team's existing Discovery work, don’t lecture them or use that as ammunition to cut them off from customer contact. Meet them where they are, ask them how you can support them, and offer to point out where you think their existing insights might miss the mark.
User research is a means to a larger end: building products that solve the right customer problems and contribute to relevant company goals. Both parties are needed to make real progress towards this end.
What are the most effective ways to measure and demonstrate the impact of UX research on product success?
The underestimated lever is the clarity regarding product goals. For most product teams, measuring their work against company business goals is not feasible because so many things contribute to them. This leaves them with what’s within their sphere of influence, which is customer behavior. And who would be a better partner than user researchers to shape this sphere of influence? How can you set goals about changing customer behaviors without understanding customer behaviors?
If you can demonstrate how reliable research informs the setting of (and execution towards) product OKRs, you're making big strides toward demonstrating the real-life value of your work. I think many researchers shy away from this area but can make the most significant impact there.
What is the best format to present insights compellingly to PMs, considering they are always busy?
Treat research insights like a product and ask yourself: What problem does this have to solve for whom? In this case, it means that the product managers look for reliable evidence about customer behaviors that they can use to prioritize their work.
So, pick a format that makes it easy for them to continue working with these insights. If your company is big on JTBD, ensure your presentation ends in weighted job statements. If you utilize decision trees, show how the problems found can be turned into outcomes on an impact map. If they must convince the board of a shift in direction, ensure the summary is shared in a presentation using the company’s CI. Remember that formats like a pains/gains map or something similar are only means to an end, so pick them accordingly and leave the research report for optional and sync context.
HOW TO PUT THIS THEORY INTO PRACTICE
Focus on skills, not roles. Identify what is needed to reduce uncertainty next and assemble the people who have the skills required to do so.
Partner, don't outsource. None of the two domains are bound to serve each other. Both should share an intrinsic motivation to make real progress toward strategic goals. Frame the work accordingly.
Prepare based on empathy for each other's roles. For PMs, that means coming up with research intent questions instead of vague interview questions. For UXRs, that means presenting insights in a format related to product work, not abstract research study formats.
Did you enjoy this one or have feedback? Do reply. It's motivating. I'm not a robot; I read and respond to every subscriber email I get (just ask around). If this newsletter isn't for you anymore, you can unsubscribe here.
PS.: Do you Interview Users? Do you have “no shows”? Fill out this short survey to learn more about a free productized solution to that.
How to Dive Deeper into Product Discovery
A Practical Guide to Using OKRs in Product Management: This hands-on guide goes beyond the average "best practices" of OKR basics and instead focuses on the real challenges of Product Teams for using OKRs in addition to Product Discovery, Roadmaps, and Scrum.
Shifting from a Feature Factory to Continuous Discovery at Doodle
My key learnings from the workshop were three things. Number one: My team had a hard time defining what a problem is, what a hypothesis is, what the difference between a hypothesis and an assumption is. How did we figure that out? I asked them to define a problem statement for the number one problem we’re all aware of, where we do have research and data and we all know that this is one of the biggest problems and I asked them: turn that into a problem statement. Fifteen people and it took us 20 minutes to come up with a problem statement that was a true problem statement.
No, AI user research is not “better than nothing”—it’s much worse
Compared with the incredible value of things customers have actually said, things that sound like customers might say them are worthless. And yet that’s exactly what LLMs do — produce text that appears plausible. An LLM can’t talk about the last time it had to accomplish a task. It’s impossible to drill-down to understand how the use of a product intersects with its context because it has no lived experience. Unlike a human being, varying your prompting will never reveal anything that isn’t already in the model — the insight that separates products from commodities. All the model can do is put those words in a synthetic mouth.