An interview with Paul Adams

About Paul Adams

Paul currently works as a Product Manager at Facebook. He is the author of the book Grouped and is recognized as a leading thinker on designing social interactions. Paul spent four years at Google, leading user research for their social web projects. Before Google, Paul worked as a User Experience consultant at Flow, leading research and design projects for clients including the BBC, The Guardian, Vodafone, UK Government, and Betfair. Before that, he worked as an Industrial Designer, designing electronic appliances at Dyson and car interiors at Faurecia. Paul is a strong advocate of observing behavior in peoples' own environment, and believes that this helps to create compelling experiences, and he writes a popular blog at


Main points

  • The most important thing is developing empathy to your stakeholders. We do that with our users, less with our stakeholders.
  • We should better understand what our stakeholders need and align our actions with those needs.
  • It’s important we understand the product roadmap, what are stakeholders’ priorities, and the reasons for deciding to building things. Understanding that will make you understand what type of things they will better respond to.
  • It is hard to engage people in field research since it is unlikely they join field observations conducted outside of the office.
  • Instead, conduct dual studies. When you are asked to run a usability test, do it. Add extra time to the usability test session and do your own thing. In many cases, your stakeholders will be more interested in the part of the session they did not request.
  • When I had weaker relationships with my team, I used designers as proxies to my research. I try to influence the design with research.
  • I’m a big fan of physical artifacts as research deliverables. I design huge posters with many details and put them in places where my stakeholders are hanging out. The information in the posters is being consumed in nuggets over a period of 3-6 months.
  • I always provide recommendations since I have a background in design. I have however seen excellent researchers who do not provide recommendations, believing they should keep an impartial, objective position.
  • I measure my work by impacting code that either shipped or didn’t ship.
  • When you push too hard, people are more likely to push back and poke holes in your research.
  • Measuring impact is hard. To me, it is more of a gut feeling.
  • There are many reasons why product managers and engineers decide not to follow research results. In many cases, it is not because they think the research is not good.
  • There are other business reasons for making such decisions.
  • You may feel people aren’t changing things, but your posters, presentations, and reports make changes you may not be able to understand, and that’s okay.