AMA: Miro Group Product Marketing Manager- Enterprise, Mandy Schafer on Influencing the Product Roadmap

In my experience, prioritization for what's being requested in the roadmap can be done in the following ways: 1) Identifying customer need/ask: Sometimes this is the easiest way to determine which products should be built next. However, this can lead to misalignment with your overall product strategy. 2) Cost analysis - what's the ROI on this feature, how long will it take, how quickly can this start bringing in customers, or expand existing ones. How much does it cost IT. 3) First to market - how far behind, or ahead of the competitor are you on this. Will building this be for catch up, or put you ahead?

As the PMM, you often may know more about the product that the product may know. This is due to the nature of PMM having a birds eye view across the entire company with how your features fit in with the rest of the solutions. As the eyes and ear on the market, you are also know your competitors, the market landscape, and what your customers are expecting. All of this knowledge is key to help with the early stages of product developement. A lot of times, product spends so much time focusing on the core use problem, that they sometimes forget to "zoom" out, and that's where PMM comes in. Being involved early helps influence how the product should be built and ensure it fits in with the overall marketing strategy and vision of the company.

Recently, the way my PMM teams have been structured has been Inbound (or Core, Stream, etc) and Outbound (GTM). This type of team structure divides up PMM teams with those that 1) Work closely with GTM - sales plays, customer advisory boards, ABM camapign and 2) Those that work closely with Product, Engineering and UX design - Product roadmap, launch preperation, sales enablement, demos, etc. I find this to be the most ideal when being asked to influence product roadmap is a core part of your job. However, this does take away from your ability to influence MQLs, as your role becomes much more technical, and less around structuring how sales and marketing align together. I've done both, and it really depends on what you enjoy doing. I also ask my own team what they enjoy, and try and make sure they work closer in areas that they feel they can make the most impact. 

It's definitely should never be about just one thing - the customer wants it, our competitor has it, etc. This is a mistake that's often made when product teams build without including PMM, or other teams. There is that requirement to have multiple levels of evidence before a decision is made, however one I think is most overlooked is - ROI, mainly because it takes so much time and effort. I started my career as a financial analyst, and spent my days doing line by line forecasting of our product SKUs on a monthly basis to understand what our projected revenue forecast would be. I've tried to bring this discipline to my work as I suggest product features to be built. This additional information, whether or not we can expect return on investment by having it or not should be calculated, and I suggest PMMs try and work more with finance. It can be done based on current requests (win/loss analysis), growth rates, and understanding the type of customers that tend to buy, then working with the finance teams that are already doing the growth analysis and revenue prediction to identify how this new feature could impact based on the cost to build it. We are working on a similar project at Miro, looking at the overall cost from engineering support requirement, customer support, infrastructure costs, etc. Having this level of evidience along side your market research becomes invaluable. 

I work closely with analytic and strategy experts at our company to perform the market research required. At the end of the day, I'm a PMM, not a trained data scientist, nor a researchers, our jobs as PMMs is to help shape the the research, to ensure we ask the right questions, and leverage the results to help find the answers needed to shape the roadmap. For example, I've done a pricing and packaging project in the past around which new products we should build next, how to package them, and what pricepoint they should be at. In order to do this, I partnered with 1) The competitive analysis team and the analyst research to understand the market landscape and our buyers. 2) The UX design team to help us understand the way our current customers use our product and understand what we are lacking. 3) The market insights team to run survey with external and internal users on willingness to pay, and appetite for specific product features at certain pricing points. 3) Strategy Finance team- to run price analysis and stimulate how much ARR would see in return if we priced new products at certain points, over X amount of years, based on current growth rates. I then take all this information and formatted in a powerpoint presentation, (now a days- Miro boards ofcourse!) to share the information. Throughout the years of sharing information, I've always been a visual sharer. The best way for me to explain things are through charts, graphics, etc. Too many words results in losing the attention of leadership, no one wants to read! Same with numbers on a spreadsheet. However, a combo of this, in easy to digest, step by step format works the best for me. 

Sharing roadmap is essential for any tech company, and I'm a firm believer of sharing more information with customers brings more trust, and better relationships. Currently at Miro, we share our roadmap in a monthly webinar that we give to our existing customers. This is a closed webinar and invitation only so we are more free to discuss what's coming without worrying about affecting revrec. We also have a more polished customer facing roadmap, with things on it that we are more certain are coming, this is shared with prospects and existing customers. Finally we run CABs- customer advisory boards, where we also share external roadmaps with customers.

Similar to most of the other companies I've been at, we do quarterly OKR planning with the Product, Engineering and Design teams. Miro has become more and more Enterprise driven, and as a result, much of what we build is a combination of features that help us become more Enterprise ready (security and compliance ready) and a list of customer requests to manage users. During this OKR planning process is when PMM and PMs work closely together to confirm and finalize the plans on what we want to launch and build for the quarter. However, this is not the only time when we decide on what to build next, throughout the year, we both work with UX designers, get on calls with customers, and brainstorm based on industry standards on what to priortize and how to build it. 

This is a really important topic, and for me, what's worked well is setting up what I call the product maturity model. Sometimes, the product team just gets too much into the weeds of the product, and the day to day problems our users are facing. Its important for teams to step back and look at what are we really trying to acheive with our product, what should the product look like in 5 years, what is the "perfect" scenario. I always joke, how do we build a product to the point that we don't have jobs anymore? A product maturity model helps lay out how your see your customers using your product today, tomorrow and in the future state. By building one out, it helps teams understand the longer term value of what your product is for your customers. Visualizing this helps teams also see the gaps, and undestand what's important, rathering than solving for problems at that specific moment.