The User Research Strategist: UXR | Impact | AI

The difference between being a researcher people rely on and a researcher people build with
I have spent a lot of my career being the person who shows up to the meeting, sits at the table, and somehow still feels like a guest at it. You know the version of this, where everyone is aware research exists, they will happily call you when something needs validating, and yet none of the actual product decisions seem to happen anywhere near you. I have come to think this is one of the quietest career traps in our field, and I do not think we talk about it enough, so I sat down with Priyanka Kuvalekar, a Senior UX Researcher at Microsoft who leads research for Teams Calling and agentic AI experiences, to get into the part of the job that has nothing to do with method and everything to do with people.
Priyanka has eight years in the field, a background as an architect before tech, and a way of describing cross-functional work that made me nod so hard I almost knocked the mic. This one is for anyone who has ever felt like the team’s resident data nerd and wanted to be something more than that.
What we get into:
* A relationship means people know you are available, a partnership means people build with you. This was the line that organized the whole conversation for me. Priyanka draws the distinction cleanly by defining how a relationship is the PM passively knowing research exists and reaching for you when they want more of it, and a partnership is being invited into the room where the decisions actually happen, from the small “there’s a bug, we need feedback” moments all the way up to “we have a brand new idea, where does research fit.” The shift she describes is from waiting to be invited to proactively shaping where the product is going, and I think a huge number of researchers are sitting in the relationship box right now without realizing there is another box entirely.
* Sometimes the most strategic thing you can do is act like a therapist. Priyanka said she will literally sit with her cross-functional partners and work to understand what motivates them, what they are worried about, what keeps them up at night, where they see the product going, and what risks they genuinely want answers on. She called herself a therapist at one point, and I loved that, since the listening she is describing is not soft or passive, it is reconnaissance. When you actually know what your PM is afraid of and what your designers are carrying in terms of product history, you can position your research where it will land hardest, and you stop guessing at where to make an impact.
* You get proactive by questioning the decision, not just delivering the study. The move Priyanka described that I want every researcher to steal is using the five whys on your own stakeholders. When a PM brings a decision built on generally available knowledge rather than verified sources, she asks why they are taking it, where the data came from, and what the consequences of being wrong actually are. She asks for the roadmap, the six-month plan, the reasoning behind the sequencing, and what comes out of that is the context you genuinely cannot make good calls without. The reframe here is knowing what your team is building for, not just what they have asked you to test.
* The data does not change, the translation does. This is the one Priyanka named as her core takeaway, and it is the difference between a report that lands in a deck and a report that moves a decision. The same finding gets framed in tradeoffs and risk for PMs, in feasibility for engineers, and in business vision and risk-of-inaction for executive leadership, all without diluting what the research actually says. She pairs this with a research point of view in every report, where the insight comes with a recommendation, a severity rating, and a clear justification of why a high is a high and what happens if the team ignores it. Translating is not softening, it is meeting each person in the language they already think in.
* Tell people how NOT to use your research, out loud, every time. This is the bit I have rarely heard anyone articulate as clearly as Priyanka did. She has watched teams take one insight out of an entire study and bend it into whatever they already wanted to do, and she has seen people pull inspiration from unrelated reports in other departments and treat it as evidence for their own product. Her answer is to keep evangelizing after the readout, give a clear TLDR of what the research says, and then state plainly what the research does not say. Disclaimers on how not to use the data sound almost paranoid until you have had a stakeholder cheerfully misquote you in a leadership meeting, and then they sound like the most reasonable thing in the world.
* You can say no without saying no, and you can stay visible without becoming a yes-researcher. We both confessed to the same arc, going from reactive to overcommitted to burnt out, and Priyanka had the most practical fix I have heard for it. When her team was packed for four months on foundational work and the usability and “does this button work” requests kept coming, she opened a 30-minute weekly research office hour where designers could bring quick questions and she would help launch something low-lift on a testing platform, which built real goodwill without blowing up her roadmap. She pairs that with weekly check-ins where she shares even tiny progress, so the question her team asks shifts from “what is that researcher even doing” to “what is coming next from them,” and that small reframe is what buys her the time to do thorough work without disappearing for eight weeks at a stretch.
None of this works as a one-time performance. The therapist conversations, the office hours, the weekly progress updates, the disclaimers on every readout, all of it is maintenance work that you have to keep doing even on the weeks you are slammed and would rather hide behind a study. Priyanka has been sharing weekly updates for over a year, and I think that consistency is the actual product, not any single clever framing. If you take one thing from this episode, take the relationship-to-partnership distinction, and then go do the unglamorous, repeated work that earns the second one.
Watch or listen to the full conversation above. Priyanka is genuinely lovely and far more generous with her hard-won lessons than she needed to be, so go give her a follow.
Find Priyanka:
* LinkedIn
* Instagram
Interested in sponsoring or advertising on this podcast? I’m always looking to partner with brands and businesses that align with my audience. Book a call or email me at nikki@userresearchacademy.com to learn more about sponsorship opportunities!
The views and opinions expressed by the guests on this podcast are their own and do not necessarily reflect the views, positions, or policies of the host, the podcast, or any affiliated organizations or sponsors.


This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.userresearchstrategist.com/subscribe

This is a free preview of a paid episode. To hear more, visit www.userresearchstrategist.com

I’m hosting a free 30-minute lesson on how Claude skills can be impactful and useful for user researchers on June 30th at 5:00pm BST (UK time). You’ll learn what skills are and how I apply them to my work. Recording will be sent out to all those who join (plus a discount code to my next workshop!).

This is a free preview of a paid episode. To hear more, visit www.userresearchstrategist.com

👋 Hey, I’m Nikki. Each week I write about UX research strategy, communicating impact, and using AI to do your best work. For more: Claude Skills Bundle | AI Prompt Library | Team Training | Live Courses
P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-cour…

This is a free preview of a paid episode. To hear more, visit www.userresearchstrategist.com

👋 Hey, I’m Nikki. Each week I write about UX research strategy, communicating impact, and using AI to do your best work. For more: Claude Skills Bundle | AI Prompt Library | Team Training | Live Courses
P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-cour…

👋 Hey, I’m Nikki. Each week I write about UX research strategy, communicating impact, and using AI to do your best work. For more: Claude Skills Bundle | AI Prompt Library | Team Training | Live Courses
P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses
I have been thinking a lot lately about the part of research that I find genuinely the hardest, which is not the research itself but the translation work that happens after, where we take what we learned and try to turn it into something a designer can prototype, an exec can act on, or a product team can build into their next sprint. Most of us know what good research looks like, and I think most of us could write a clear interview guide in our sleep at this point, but the harder skill is being the connective tissue between what we found and what the team does about it, and that is the part of the work I keep wanting to get sharper at.
This video is a walkthrough of three workflows in Askable that I have been using to make that translation faster and more directly tied to the metrics stakeholders care about.
What I cover:
* Designer briefs that turn findings into something a designer can actually prototype. I walk through the prompt I use to generate a designer brief that includes the top three to five most impactful unmet needs, the core user problem, specific behavioural improvements I am hoping to see, and the open questions a prototype could test, all tied back to business and team metrics. What I love about this workflow is that Askable has buttons that push the brief directly into Figma Make, Lovable, or Replit with the evidence cited inline, so designers stop sitting in the in-between state of “what do I do with this?” and can start exploring concrete concepts they can test. I find that this part of the workflow has been one of the bigger bottlenecks in my own practice for years, and being able to remove it has changed how quickly research turns into something tangible.
* Executive summaries that respect how little time execs actually have. I have lost count of the number of times I have sat down with an exec, prepared what I thought was a tight presentation, and watched them check out by slide three, so the prompt I walk through here is built around getting to the point quickly, with three insights, each one including the problem, the business impact, the supporting evidence, the next steps, and why it is prioritised, tied back to metrics the company cares about. When I do not know the specific metrics a team is tracking, I default to the pirate framework, acquisition, activation, retention, referral, and revenue, since I find that those tend to work as a reliable shared language across almost every product team I have worked with. I also walk through how to layer in industry benchmarks without fabricating numbers, which matters a lot when you are presenting to stakeholders who will go and check your sources.
* Customised reports for different stakeholders without writing the report ten times. One report has never really served everyone, and I think most of us know that, but most of us also do not have the time to write a tailored version for each team in the company. The workflow I walk through here lets you drill a single research study into different views for different audiences, so the loyalty team gets the loyalty cut, the IA team gets the IA cut, and execs get the strategic overview, all without starting from scratch each time. This part of research has historically been a capacity problem for me and for almost every researcher I know, and being able to address that with a workflow rather than with overtime is something I have genuinely appreciated.
* The link between prototype opportunities and real metrics is what makes research stick. One of the things I appreciate most about this workflow is that every prototype opportunity is scored on complexity and evidence strength, and tied to specific business outcomes through the pirate framework. The reason that matters is that the hardest sentence for any researcher to earn the right to say is “my research directly moved these metrics,” and when the opportunities in your report are already mapped to the metrics your team is tracking, that sentence stops being aspirational and starts being something you can say honestly in a stakeholder meeting. I think a lot about how to make research feel less disconnected from the business, and this part of the workflow has been quietly useful for me on that front.
* AI is the glue, not the replacement. The thing I keep coming back to in my own work is that researchers are the connective tissue between evidence and decisions, and I do not believe AI is going to take that role from us. What I do think is happening is that AI is making the production work faster, the briefs, the summaries, the reports, the reformatting for different audiences, so we can spend more of our time on the translation, the storytelling, and the strategic framing that no model can really do on our behalf. Using Askable across these three workflows has reinforced that view for me rather than undermined it, and I am sharing it here because I think it is the most important thing for researchers to keep in mind when we are trying out new tools.
Watch the full walkthrough above, and give Askable a try


This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.userresearchstrategist.com/subscribe