Navigating Product Roles as a Researcher
As a former researcher, I can attest to this: we’re kind of outsiders. Picture them in their white lab coats (or in my case, a hoodie with a pizza stain on it) spending evenings and weekends locked away in a basement laboratory tinkering with all the things science. Now picture that same person inevitably leaving that role and trying to find a job in technology — I can tell you first hand the feeling of being an outsider is exacerbated. A significant part of the struggle when transitioning between industries of work is the looming question of where do I belong? More specifically, where does your current suite of skills and experience map to the seemingly endless variations of roles available in tech.
Solely based on my extensive time pulling out what hair I have left and second-guessing my journey transitioning from research to tech, it can be daunting opening Indeed or LinkedIn and performing that first job search. You’ll find what looks like endless variations of the same role, without much consistency in the responsibilities or prior experience required. Time and again, you’ll see this manifest in the search for product roles, whether that be product manager, product owner, or even product administrator — that last one drove me to an internet blackhole — I am not proud about it but dammit I need answers!
The aim of this piece is not to provide my estimation of what a good product manager job description should be, let’s leave that to the prodfather himself, Marty Cagan, nor is it my attempt to transition to a new role in talent acquisition. Rather, I’ll let this article serve to address the looming question most researchers or academics face, how on earth do my current set of skills and experiences map to roles in technology, and when I am applying to jobs, where/what level should I be looking? I’ll also try and put this in a context we’re familiar with, by comparing the career path of product people to the career path of researchers in academia.
We’ll start off with this figure:
Product Owner
We’ll start where I would logically order these roles from entry level to more senior roles, strictly from the perspective of executing and shipping products. Not mentioned in the diagram is the Product Owner. If you want some clarity on what the Product Owner role entails, one of the best resources I’ve come across is from (yet again) Melissa Perri.
I labelled this role as the most entry level based on the tactical, operational, and strategic involvement in building products. The common understanding of the Product Owner role is a backlog administrator; managing the order and value of items to be worked on by the development team. This obviously depends on the company, some organizations give their Product Owners a considerable amount of autonomy to make product decisions, talk to customers, and build prototypes. However, I’ve noticed that for the most part, organizations either (1) do not know where the Product Owner role fits in the shipping of products, or (2) organizations deprecate the role all together in favour of talented and empowered product teams. Rant over.
You can think of the Product Owner as the undergraduate researcher when it comes to the product team. The undergraduate researcher is largely responsible for the non-technical aspects of a research program; participant screening, setting up the basic equipment, and playing more of a hands off role in the execution of the experiments and analysis.
From the perspective of shipping valuable and feasible products, the decisions about product strategy and optimization are not always made here. Instead, it’s a combination of assisting the empowered product team (UX designer, engineer, product manager) to do their jobs and ensuring a validated backlog of work for a self serving work cadence.
Associate Product Manager (APM)
The APM is an entry level position for the product manager role. They spend a large amount of their days in the tactical execution of the product; working on shorter term objectives, examining and breaking down scope, and performing some data analysis on product metrics. Finding an APM role is a tough one, there are opportunities at amazing tech companies such as Google, Microsoft, and Facebook, with Canada joining in the fun with the Toronto APM Program.
To me, the APM is very similar to the prototypical masters student. In most cases the masters student enters a laboratory with an existing clear vision for the questions to explore. In large part, the student takes that question, and has the autonomy to design a research project to adequately address it. Here, you’re tailoring your experiments and prototypes from your supervisors observations, rather than having the autonomy to ask the question and do the background research yourself, or, in the case of tech, having the discretion to build the strategy for execution. This is where I’ve seen the parallels between the APM role and the masters student experience. In most cases, you’re looking deeper into the data — an area where I think researchers have a competitive advantage — looking for smaller wins rather than executing on the entire product (or research program) in a leading role. You’ll often have a lot of mentorship and guidance in this process, which is extremely valuable for building amazing product managers.
Product Manager (PM)
Getting a clear and concise description of what a PM does is almost as dreadful as answering: “so what is your thesis about?”. There is a bountiful number of resources that address these questions, one of my favourite being Dan Blumberg who gives us plenty of examples you can use if you’re ever stuck explaining what a PM does to that one aunt who you haven’t seen in years, who feels like downloading a new app on her phone is as anxiety inducing as deactivating a bomb.
The PM is the subject matter expert of the customer. This individual has to know the issues users face, gaps in the user experience, how users think, how they work, how they decide to purchase your product, etc. Additionally, the PM is responsible for synthesizing multiple pieces of data to determine the next direction or objective the team should move in. They take all this together, identify risks in the market and existing business constraints to provide a valuable solution to the end user.
To me, this is the PhD of Product. PhD students are given the autonomy to identify the research gap, design the overarching research question(s), and execute. Not only are you the expert of your domain, you know the constraints of the existing body of research, and you effectively navigate the qualitative and quantitative data from your participants to fuel optimization. All of this done in a collaborative environment with design, engineering, and stakeholders, or, in a researcher’s sense, other labs members, participants, and supervisors.
One of the best anecdotes I heard in my time in research that effectively distinguishes masters students and PhD students, and I think it transfers well to the way the product career is navigated is: doing a masters is like writing a chapter in someone else’s book, and bravely doing a PhD is like starting to write the prologue in your own book.
