What it’s like to switch from User Research -> Product Management

A while back I hung up my Qualtrics account, ethnographic field kit and statistics textbook and switched to product management. Fortunately I work at a company that supports internal movement (a very healthy quality of tech companies), and was able to start my new career path without a lot of fuss and administrative maneuvering. The lessons learned could be of interest to user researchers curious about product management — and vice versa.

Let’s start with my personal blind spots.

Context

Once at my last company I ran two long, exhausting days of usability testing, from which I had a fresh set of product insights. Users had trouble navigating to the feature. The call to action was unclear. The interaction model confused people. Armed with these findings I remember eagerly approaching my PM, ready to rock her world with my keen senses of observation and detail. I also remember reeling in confusion and anger as she then proceeded to systematically debunk and reframe every single one of my points. The navigation? Just a WIP prototype. The call to action? It had been thoroughly AB tested. The interaction model? It was a standard component. My triumphant set of conclusions had been stripped down to a small handful of UX tweaks that she “would consider”.

Who was wrong in this situation? Well, likely both us of — me for conducting research in a vacuum and her for not properly describing her learning objectives. Either way, what was missing was context.

You saw this point coming, right? Well, it’s true: product managers by necessity have to understand the entire picture surrounding the product. This was PM lesson number one: to manage a product you have to understand the whole burrito, not just the tortilla.

Context in this case has different meanings. It can mean the competing internal priorities that weigh heavily on what gets built and what doesn’t. It can mean the competitive landscape, and a reckoning of what will make an impact in that space. It can mean the history of the feature, and carrying forward what has already been learned. It can mean the technical context — despite your wishes, what is realistic? Perhaps most importantly, it can mean context in the form of prioritization — with limited resources, what are the important elements and what are just elements?

Tech chops

An unfair stereotype of engineers is that they only speak in technical terms. I have worked with many engineers who are good communicators, have sharp product instincts and can contextualize their work with “big picture” thinking. They have no trouble collaborating with non-engineers, and are pretty cool with being challenged if the reasoning is sound.

That said, holy cow you are a lot more effective collaborating with programmers if you understand the basics of software engineering. In my case I had a decent head start, having worked with programmers of different stripes and having dabbled in HTML/CSS, Python and SQL. Prior to making the transition, I had also spent a few lonely weekends reading up on basic software design. Now as a PM, my basic intuition for technical implementation is the difference between being ignored and paid attention to by my team. I am simply given more credit when I throw down a few technical implementation flourishes here and there.

But beyond any gravitas that technical literacy might lend you, you’re simply going to have a deeper understanding of product design, how to solve problems and envision new outcomes with a basic understanding of how things are built. If we are to have an opinion, or care about how a product or feature is built, we should damn well know the difference between the back end and front end — to say the least. I personally think user researchers would benefit from stepping into the weeds a little more here.

Leadership not management

Prior to joining product I worked with a wide variety of PMs, some of whom were fantastic leaders, some not so much. The bad ones would be threatened by me, tell me how to do my work or would selectively cherry pick research findings. One quality I noticed about good product leaders was their ability to motivate me to do good work without using job title, authority or explicit pressure. The good ones took pains to understand my goals for the project and then subtly guide and nudge me in useful directions. In other words, they knew how to use me.

One of the biggest facets of being a good product manager is leadership. Of course, we’ve all been exposed to Leadership Lessons encoded in various corporate parables, or even attended leadership trainings designed to impart the rules of engagement when leading teams. All of this is useful and worthy, but I have to say: when you are confronted by your first “situation” as a product manager, you’re not necessarily thinking about whether you should flex “blue” or “green” skills to disarm the situation. Leadership is a process of trial and error that often starts with blunders and misunderstandings.

This was not a muscle I was used to flexing as a user researcher. As you grow through the research ranks your professional development is about sharpening skills, and then later is more about management than leadership. Now, this isn’t to say that individual user researchers aren’t leaders — I’ve worked with and under several great ones — but I personally did not feel that I was growing this capacity on the user research track.

Perhaps this is because of structural reasons. As a senior user researcher you will have solid lines connecting you to a team of direct reports that you manage. Later, as a department head, you’ll have to mix with other cross-functional department heads, and that most certainly requires leadership skills. But at any level, product managers have to grapple with leadership on day one.

Now, I haven’t figured it out yet and I’m still in a phase where I am doubling my knowledge of leadership every two months or so. From what I can tell, humility, fairness and constant communication are pretty damn important. Foresight, or as the Swedes say: “seeing where the puck is going, not where it is” — is also key. Forming and maintaining relationships is a constant exertion.

Notice these things are mostly “soft” skills, but there’s nothing soft about them. It’s really hard to be consistently humble, to be consistently balanced, to always be searching for alternatives, etc. In my mind the best starting point is to act like a cartoonish leader like Wonder Woman or Captain America until you find your own “voice” as a leader.

Story telling

When I was at Facebook I spent nearly a month working on the Mother of all surveys. This survey was a multi-market beast with all manners of research wizardry: stated vs revealed choice, spider diagrams, key drivers analysis, correlations, even a quadrant analysis that nearly blinded me from hours staring at the screen. I loved those damn slides.

On game day I showed up and nailed it — or at least in my mind. I spoke for nearly an hour, going through a demented volume of charts, diagrams and slices and dices of data. At the end of the meeting there was an awkward silence followed by the one word that every researcher dreads to hear. “Interesting”, said the manager. “Interesting”, or in other words: “useless”.

What happened? It’s obvious to me now what happened. I did a terrible, terrible job of delivering the data in a palatable way that motivated my audience to care. I didn’t tell a story around the findings. I laid my data out with dry, clinical detachment.

Story telling is an important dimension to product management. Whereas tech chops and leadership constitute the Logos and Ethos of product management, respectively — story telling is the Pathos. But not all three (Ethos, Logos and Pathos) are created equal. Time and time again I have read and heard that delivery is 90% and content is 10%. As an inveterate introvert this has always been a depressing ratio to me. But over time I’ve learned that channeling my inner Steve Jobs isn’t so bad if it helps me get my point across.

For those interested in the full story-telling toolkit I recommend “Made to Stick” by Chip and Dan Heath.

If you are still with me…

….I will talk a little about the strengths I carried over from my research days. In many ways I have been well-served by my years in the research trenches, and in unexpected ways. Product managers pay attention!

Data orientation

Despite “big data” and “data-driven decision making” being tech industry watchwords, many PMs have yet to truly embrace the rigors of AB testing and research to inform their decision-making. Even those PMs who embrace AB testing will design tests that contain seven experimental conditions within two test cells. Where the hell is your signal coming from?

Product managers also don’t have the cleanest record when it comes to engaging with user research. For many PMs, “small sample” research is inferior to live testing, purely because of sample size. This is rooted in lack of experience and a misunderstanding of data methods. A set of user interviews, an n1000 survey and an AB test should have entirely different goals. User interviews reveal context and nuance around a topic, surveys can describe the prevalence of attitudes or opinions and AB tests are quasi-experiments that produce behavioral data.

It boils down to understanding the relative strengths and weaknesses of different methods, and when to use each. This comfort with data methods is an advantage that user researchers can carry over to other roles.

Humility

Coming from research, I am used to expressing myself with tentative, deferential language. “Maybe”, “perhaps”, “some”, “recommend”, “consider”, “investigate”, and so on. This is due to two reasons: research as a profession trades on impartiality and user researchers often feel out of place at tech companies.

Scenario: furtive user researcher with good fashion sense and degree in English approaches brogrammer wearing a darth vader t-shirt and in the midst of a Redbull-fueled two-screen coding sesh. Furtive researcher wants programmer to make client change to accommodate UX tweak.

Who has the power here? In most cases, the programmer is in the driver’s seat. The researcher has the burden on them to communicate the context, convince the programmer to act and then hover over them to make sure it’s done. The winning strategy for the researcher is to be humble and flexible in making their request.

This ingrained humility has an upside. In an industry where you can test 10 versions of your feature at the same time, those who are accustomed to examining options with impartiality have an advantage. Plus, a little humility can go a long way in an industry that has no shortage of outsized egos (although thankfully we are mostly spared of this in Sweden). Finally, you can lose a finger if you interrupt a programmer locked in battle with a relational database problem. Best to proceed with caution :)

Cross-functional comfort

The last piece I’ll say is that researchers are quite used to collaborating with colleagues of different stripes. Although some researchers embed within design, many spend their days darting around campus meeting with folks from product, engineering, marketing, copy, content, QA, customer support, legal and of course design. This experience comes in handy as a PM, as I have myriad connections with outside functions.

Another unexpected benefit of coming from research is the experience I had “selling” our tools and methods to outside teams. Working within a service function, I was used to a certain degree of internal biz dev. In order to be effective at this I had to understand the needs and desires of other functions within the company. What makes an engineer tick vs a copy writer? Now that I am continuously trying to get people to do things for me, this experience has helped me manipulate people. Did I say manipulate? I meant empathize :)

So, there you have my lessons learned.

I’ll end with an anti-TL;DR by summarizing a few takeaways

Some tips for user researchers:

  • Take pains to understand the context surrounding your project work. Perhaps embedding is the way to go
  • Spend some time immersing yourself in engineering basics, you won’t regret it
  • You don’t need a structural reason to lead
  • Tell stories around your data, people will pay attention more

Some tips for PMs

  • There are different types of data and different methods are employed to obtain this data. “Small sample” data is not inferior to live testing data, just different
  • Despite the “alpha” culture surrounding tech and product in particular, humility goes a long way towards motivating others and thinking clearly
  • Cross-functional collaboration works best when you understand what the other party wants

Hejdå!