The difference between being a researcher people rely on and a researcher people build withI 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...
続きを読む
一部表示
2026/08/0631 分
31 分