Abhiroop Basu

The simple answer is to prioritize the features that will bring your customers the most value and consequently drive the most revenue for your business/organization. Unfortunately, it's rarely that straightforward, particularly if you aren't working on customer facing features. Here are the four steps for prioritization: 1. Solicit input from your partners: It's important to identify what your design, engineering, data science, product marketing, and other cross-functional partners find important. For example, your engineering partners might want to do a tech migration, while your PMM partner might have identified a critical missing customer feature. Together with their input you can brainstorm and create a list of initiatives. 2. Use the RICE framework: Create a table using the Reach, Impact, Confidence, and Effort framework. Reach is for how many people will see the feature. Impact is for the $ impact of the feature. Confidence is the likelihood of execution and/or Impact (0-1). Effort is the level of effort (usually 1-10). The formula you can use is R*I*C/E. For example, let's say you're building a new Android app for your customer base. You know that the app will reach 100 customers, it'll grow revenue (impact) by $50 per customer so a total of $5000, the confidence is medium at 0.5, and effort is 5. Total = 500. You can then benchmark this against a different initiative. 3. Communicate your decision back to your partners: Once you've come up with a priority (either your "top 5", P0/P1, or ordered list) communicate back to your partners and ensure you're all aligned on what's most important.

One thing I've never had an issue on is coming up with features for a product. If you're ever bereft of ideas, simply go and speak to a customer and they'll provide a dozen ways your product can be improved. But it's important to structure the ideas so you don't get overwhelmed. Here's how you can go about doing that: * Brainstorm with your partners: Setup time with your partners to generate and refine ideas. You can use customer feedback as an input * Vote/prioritize on the top ideas: Give everyone a vote and see which ideas people care about the most * Refine: Go deep on a handful of ideas and come up with a workable problem or hypothesis statement for that idea

Prioritizing is one of the hardest tasks for a PM. Balancing the needs of stakeholders, with customer needs, and business priorities. However, only your manager (and their manager and so forth) should have any "control" on your roadmap. Everyone else, should be able to provide In reality, you will find other stakeholders will expect some level of influence. Once you've identified the initiatives for your team, you should use the RICE framework to prioritize them (see my other answer on this topic). This will give you a clear framework when discussing priorities with other stakeholders. For example, if sales is insistent that customers need a specific feature, you can show them that there are other features which have a higher RICE score. This may or may not always be effective, but it's a consistent approach that can be used with everyone. There will be times that RICE scoring will not be enough. In these scenarios, it's important to hear out your partners and give them the opportunity to make their case.

Some companies do a great job in providing a public-facing roadmap. At one company I worked at, there used to be a Trello board where customers could add features, upvote, and see what was coming up. It was completely transparent. On the other hand I've worked at companies where we didn't publicly list anything. There are good reasons to do both. At smaller companies being transparent can help build community, engagement, and enthusiasm for your product. You are also at low risk of having bad publicity if dates slip. You should strive to include details of the features, mockups, pricing, and anything else that might be relevant. At larger companies, you'll need to work with your marketing, legal, and sales partners to coordinate what is published. For example, you don't want to list that something is being worked on when sales has communicated a different feature is the priority. It's also important to provide disclaimers so that customers don't use any dates/targets as a means to renegotiate their contract when something slips. Finally, you'll want to make sure that you aren't sharing too many details about a feature until they are confirmed. If there are companies relying on your product for their business then accuracy is critical.

Depending on the team in question the level of detail and approach will differ on how you communicate your roadmap. Here are some of the key teams you'll partner with and approaches you can take to communicate your roadmap: * Core team: For your design, engineering, and data science partners you want to get into the weeds. Typically you want to share every element of the roadmap and more specifically the requirements for each and every feature. After all your core team are responsible for building the features. No detail is too small! Communicate early and often. * Partner product teams: For most larger companies, it's likely you will be working with other teams. For these teams you need to identify which features those teams will care about. You don't need to tell each team about all the features you're building. Highlight the important ones and explain why they need to know about it. * Product marketing: You'll want to share everything customer facing with your product marketing partners and work with them to craft the benefit/value statement for each feature. Your PMM partner is responsible for marketing the features to customers, so it's important they understand the why, what, and how of the feature. They need to know everything, minus the technical implementation. * Sales: Sales will typically work with Product Marketing, so you don't necessarily need to create something separate for these teams. * Customer success/support: Success and support will need to know what to do when things go wrong. So you should have a clear FAQ or table that highlights potential issues with each feature and ways to diagnose it.

This is an interesting question, but it's rarely a decision an individual product manager makes. Even if you're the only PM in your company, there will be PMMs, business development, sales, not to mention your leadership team who are all part of setting the priority/direction for the company. There isn't any point in you building a feature for existing customers if sales is focused on signing up new users. If you're company is new or young, customer acquisition is likely the bigger priority. In this case, you should focus on building new features to sign up new customers. In contrast, if your organization is more well established prioritizing existing customers will be the goal. Ultimately, though, it won't be you making this decision in isolation. Look to your organizations leadership to see who the target segment(s) should be.

In almost all cases you want to have Product Marketing creating the roadmap deck and delivering it, rather than Product. There are two main reasons for this. First, some PMs (please don't hate me) tend to focus more on describing the feature rather than articulating the value and benefit. Of course there are many skilled PMs that can do both, however it’s unlikely all your PMs will be able to do it consistently. Customers don’t care about the specifications of the feature, they want to understand what problems it would solve. It's the Product Marketers job to make the connection between the feature and its real world benefits. Second, you want to provide a holistic roadmap that tells a unified story. So, it makes much more sense to have a Product Marketer understand the different features that are coming and weave it into a narrative that is relevant for the different segments or verticals you are targeting. Even if a Product Manager is able to describe the benefits of a feature, it’s unlikely they have the time to look across all the other products and weave them together. So, Product Marketing should create a roadmap that sells the benefits and tells a clear story to the customer. Sales and Success can then take this and present it to the customer as part of their regular meetings.

It comes down to which aspects of the role excite you the most. Depending on the company you are working at, Product Marketing and Product Management can have a lot of overlap. I’ll first discuss some of the similarities and differences in the roles before summarizing how you should think about making the choice. Early in my career I found this Medium article instructive in deciding which path to pursue. Product Marketing really has two sets of functions, “outbound” activities and “inbound” activities. Put simply, “outbound” Product Marketing focuses on activities like developing marketing collateral, sales enablement, go-to-market strategy, targeting specific customer segments - all with the goal of driving product adoption. These activities are core to any Product Marketing role at virtually all organizations. “Inbound” Product Marketing deals with the question of what to build and what goes on the product roadmap and this often overlaps with the role of Product Management. The article I linked to above, has a helpful spectrum which illustrates the different stages of product development. In smaller organizations, the role of the Product Manager is hired first and includes a lot of the traditional “inbound” Product Marketing functions, including figuring out what market segments to go after, what order to go after them, what customer/user types to prioritize, etc. In larger organizations, the role of the Product Marketer starts to fulfil many of those same functions. So, summarizing and answering your question: * First, identify what areas of Product Marketing you are interested in. If it’s the “outbound” activities (like developing marketing collateral, sales enablement, etc) you are clearly going to be more satisfied as a Product Marketer. If, however, you prefer the “inbound” activities you might still find a great Product Marketing role, but Product Management might be a better fit. * Second, look at the size of the company. In smaller companies a Product Manager is likely to be doing the majority of the “inbound” activities. It’s unlikely you would have the opportunity to set product strategy. So, if you want to work more on developing the product strategy and roadmap you either need to move to Product Management at a smaller organization or look at PMM roles at larger companies (>500 employees). * Finally, it’s important to think about your long-term goal. The Product Marketers career-path leads to the CMO role, while Product Managers will probably become CPOs or CTOs. Long term, which role do you see yourself in?

You would assume that being in the product organization would allow a PMM more influence. However, I’ve actually found the opposite to be the case. For a brief period of time at Zendesk, Product Marketing reported into the product org. This let us foster very close relationships with our product counterparts. We would go to all their meetings, offsites, planning sessions, etc. and be joined at the hip when it came to launching features. As a junior Product Marketer this experience can be intoxicating. The compromise you make though is that it’s the Product Managers that are the ultimate decision makers. As a Product Marketer, I more often than not, would play a supporting role in ensuring a feature launched. In the last 4 years at Zendesk, Product Marketing has reported into the CMO and this has allowed the team to become far more strategic. When Product Marketing reports into the Head of Product, your role becomes supportive and the goal becomes making a product launch successful. This is laudable, but you don’t get much of an opportunity to influence the roadmap. Reporting into marketing, let’s PMM keep product at arms length and take an unbiased view on what’s important. It also let’s PMM align closer with sales (and by extension customers) to get an unvarnished picture into what’s working and what isn’t with respect to the product. So, sitting outside of product allows PMM to be better overall partners. However, coming back to your questions, are PMMs better able to influence the roadmap if they report into marketing? This is trickier, but in my experience the answer is "yes". As long as you have the credibility, sitting outside of the product org allows a PMM to bring a holistic picture of what customers need and by extension what needs to be built. It also allows PMM to bring an outside perspective (e.g. from sales) that product may not have. My colleague Teresa Haun has written a great answer on why PMM should report into Marketing and not Product: https://sharebird.com/where-should-product-marketing-report-into-product-management-or-marketing.

Both roles are quite tough to get into without experience, but PM is marginally easier. 1. Companies will typically have more PMs than PMMs. The PMM to PM ratio is roughly 1:4. Even if the company prioritizes PMM roles, it's rare that the ratio will get higher than 1:2. 2. There are fewer PMM roles in the industry. Just doing a quick search on LinkedIn shows that there are about ~100k open PMM roles, while there are about ~280k open PM roles. 3. PMs typically get hired first. Most companies will start with PMs. This is unsurprising since the goal at early stage companies is to build the product and get to product-market fit. A PMM role, while important, is usually secondary. 4. (counterpoint) PMM has a wider pool to draw from. Most marketing, sales, and biz dev roles, can transition into entry-level PMM roles. In contrast, there are fewer paths into being a product manager (common ones are business analyst and engineering). Finally, it's worth highlighting that, in general, both roles are hard to get into. There are very few entry-level PM or PMM roles. If you only have an undergraduate degree you are unlikely to land a PM or PMM spot. I've had many colleagues who've had extensive careers, done an MBA and then transitioned into a PMM role. Similarly, many PMs come with long software engineering backgrounds. If you are a new graduate and looking for a PMM or PM role, I would recommend looking for PM internsips and transitioning this into a full-time position (PMM internships exist but are less common for the factors mentioned above). The alternative is to go into one of the other careers mentioned above (marketing, sales, biz dev before going into PMM or software engineering before becoming a PM).