AMA: Facebook Former Product Marketing Lead, Measurement, Alex Lobert on Influencing the Product Roadmap

I suggest that you start by taking a step back to really diagnose the problem. Why is it that the team wants to ship so many features? I try to always assume good intent. With that in mind, the team's actions are probably logical, but there is either mis-alignment on the goal they are optimizing for or the process that will best get to the goal. Start by getting on the same page about the goal. Do you have the same undersatnding of vision for the future of the product? Are you focused on the same metrics? Are you building for the same segment of customers?... Does the product team well understand that segment of customers? Once you're aligned on the goal, then align on what approach will best get you there. Why is shipping 3-5 features better than 20? What are the pros and cons of each approach. If you can tell a good story about why your approach is best to achieve a shared goal, you just may change their mind. If the root cause is that the product team doesn't understand the segment of customers well enough, that is great signal that there is need for research or a customer immersion. Consider getting your product team in front of your customers so they can hear first hand what their needs are.

During roadmapping, each product team articulates the "understand needs" for their product area and what we will do with the information to improve the product. This process is often led by the PMM. From there, we work with the product team to document hypothesis to test based on information we need to know and detail the best approach to prove of disprove those hypothesis. At that point, it's all about execution and pulling together what we learn in a compelling way. With regard to systematically influencing roadmaps, I feel like this is an "always on" job. First, I try to bring the product team along while research is done. That might mean having engineers and designers sit in on customer interviews or sharing early learnings during team meetings. While I typically recommend having some kind of "report out" - as a memo or a discussion / presentation. The final product shouldn't be a surprise. We often do recaps of everything we learned on a given area at the end of a half, but I find that the real "influence" happens consistently over the course of a year when we share what we learn in ways that can be debated and then acted upon. Also, very tactically, I find opportunity sizes are really important. Make it clear what you expect will be gained by acting on your findings / solving a need. Findings without opportunity sizes are often a hard sell. 

The first piece of research is typically WITH the product team - aligning on the key things that we don't know, but need to know to make better product or feature decisions. Upfront you should lay out that we will try to learn X in order for us to decide whether or not to do Y. If you do this upfront work, you will have such a better chance of making an impact with your research. From there, it is all about determining the techniques that will allow you to leran the requisite piece of information and/or test necessary hypothesis. I try to start "low cost" whenever possible. This may be competitive research / using a competitors platform to figure out how others solve a problem, doing research as to what industry analysts (eMarketer, etc.) or users are saying about your or competitive tools online (twitter and youtube can be great sources of feedback). Plus don't forget to talk to your sales / customer success team if you have one. If those approaches can't get you the information you need, there are always more time intensive approaches like setting up customer interviews, survey research, and diary studies. Tangibly though, I find that the output usually looks something like: * What we learned * Why it matters: * Implications for the product * The opportunity size of those implications * How you got the information: * The process by which you learned the information for purposes of driving trust

I find it both tricky and exciting to share your product roadmap with customers. I agree it's hard to strike the right balance of specific yet not tie your hands. But also, it's so much fun to show people the exciting ways you plan to help people. Some considerations: (1) Share the overarching themes as to where you are going. These are typically pretty static and there is little risk to explaining the big things you want to accomplish. Also, these are aspirational and typically fun to talk about. (2) Connect your overarching themes to some, but not all tangible features or launches that will be coming. You don't need to be exhaustive as to all the features you have planned. Pick a few that you feel are exemplary and will get clients excited to join you on your product journey. (3) Make it clear when you have less precision as to what the product will be and / or the timing of launch. I regularly give less than precise timing for product launches (expected launch in H1), when we aren't sure when a feature will launch. Further, you may need to clarify that a UX design is a mock / not final. I find that many clients appreciate this transparency - especially if you can explain the driver for the uncertainty. Also, written disclaimers are your friend if you are worried about legal risks. (4) Set expectations about when you will have more detailed information to share. I suggest getting into the habit of regularly updating materials as you get more info. 

Two mistakes I've seen are: (1) Not getting on the same page as to the goals for the product. If you don't have a shared undersatnding with your PM / your product team as to what you are building and who you are buidling for you are likely going to provide insights that miss the mark. More hurtful than not providing persuasive insights is the risk that the PM / product team will not perceive you as an invested member of the product team. This doesn't mean you have to agree with everything, you may need to disagree and commit to some goals. But I suggest always persuading from a shared understanding of the end goal. (2) Not running an inclusive research process. When I first arrived at Facebook one of the PMs I worked with asked me "how was I going to ensure that the inbound I did was impactful when it may take months to complete." The implication being that PMMs often disappeared from the product team to go to research only to come back when they had polished insights. Don't be a PMM that disappears. I suggest trying to make your research process as inclusive as possible. Engage PMs, engineers, design in defining the questions we need to answer / hypothesis to test, invite the team to customer interviews when possible, and share early results. I find this is not only effective but avoids the risk of delivering info that misses the mark and strengthens your relationship with the rest of the product team.

I find that the key difference between influencing a 3 year product vision vs. features for the next quarter are about the precision / availability of information. The next quarter can typically be assessed pretty clearly. You can talk to customers / do research into what their needs are now and you can often make some predictions about what the benefit will be addressing that need. When influencing a long-term product strategy, you often have to identify static needs / jobs to be done for a client and long-term trends. For example at Facebook, it's pretty clear that businesses still want increasingly efficient ways to acquire customers and at the same time there is an acclerating trend toward a more private internet. I can bank on these factors when helping to determine what to do next. At the same time, you'll also want to help the product team make "good guesses" when things are less certain. For example can you draw on analogies from other industries to give an idea of where your market is going? I will also note that I recommend thinking of long-term visions as "living documents". It's your best guess at a point in time as to the future. You will likely need to revisit it regularly as you get more information about what is coming. 

I find diverse experiences to be valuable to product marketing. When I think about research and influencing the roadmap, what is most important to me is: * Can this person create a data-driven argument for change? That could be getting a client to adopt a product or changing an internal process. * Are they a strong project leader and can they organize diverse teams to get stuff done? This is a universal skill. Product Marketers often have to tackle ambigious problems and do so with a diverse, cross-functional team. Think of examples of how you've done this in the past. * Can they clearly communicate their ideas - and do so to different audiences? Especially can they clearly communicate customer needs?