Jessica Webb Kennedy

PMM wears so many hats it's important to recognize what is needed at any stage of a company. When first coming into an organization as the first PMM I think the most important thing to do is establish what does and doesn't exist - and where the biggest holes that can be plugged are. This can be accomplished by interviewing the top stakeholders at your company: Sales, Product, Support to understand what is working and where the pain points are. From that, you can build a list and prioritize it accordingly. Using something like an Eisenhower Matrix exercise can be a great way to knock out things that have to happen - maybe you also pick a few "easy wins" to support the team right away. That being said, I think when starting at a company as an initial PMM you have to square away certain areas before beginning others - the #1 thing you have to do first is to talk to users, active, churned, big, small - this will inform a lot of your next steps - I think next comes positioning, which entails competitive analyses as well, then some level of sales enablement, which is a part of a larger GTM initiative.

This happens a lot, PMMs are brought in quite frantically once a team already has a very specific way of working and it's on the PMM to figure out how to slot themselves in. I think the first thing that needs to happen is to clearly delineate and articulate team members' roles and responsibilities - Atlassian actually has a great guided playbook you can run with your team to do just this! Doing the above ^ creates a space for the team to better articulate and understand their own roles and those of their teammates. I find one of the biggest blockers in having a great working relationship with Product Management is misunderstanding or disagreement on who does what. Often when the PM team has been around for a while they may be used to doing certain things that actually are your job now! So identifying these areas and having an ongoing dialogue about them can mitigate a lot of these issues. The other thing I'd encourage PMMs joining a company where Product Marketing is new is to remember that it's your job to showcase your skills, experience, and value. Coming in it's a great plan to setup 1-1s with key stakeholders, to write up a blog on something like Confluence , or make a presentation at a company meeting about who you are, what you've done, and what you are there to do. Think of this as your internal campaign to get people on board with your mission and vision - it's much easier to do this upfront and broadly rather than starting from scratch with each launch, project, person, conversation etc.

A great way to think about framing your messaging is by starting out with a short paragraph outlining who you are talking to and why they should care or need your solution/product. At Atlassian, we often start with these questions: Is this how you want your product or service to be represented? Are you appealing to the right audience? This is a good framework for laying out this information and keeping it top of mind as you formulate your messaging. I'll make another pitch for creating an overall messaging house for your brand/product to be able to come back to over time and use as a launching point for specific features/GTMs. This is something that will make your job so much easier and not feel like you are starting from scratch each time you try to set up the messaging for a launch.

I'd start with the data! This may mean tapping your data analysts, marketing analysts, basically anybody who is knee-deep in the metrics. What I would do first is attempt to map out the funnel for the product in question (if this doesn't already exist) - figuring out how people get to your website, what they do once they arrive, and where any significant drop-offs may be occurring. In this case, if you are more focused on retention then I'd look at what users are doing once they are in the product, how long they are sticking around (or not), and try to pinpoint any significant data points for these users - for example, if you notice that users with a certain team size are more likely to remain active after two weeks, you may decide it's worthwhile to encourage inviting teammates as an initial step in product onboarding. Once you discover something like that ^ it's all about figuring out where to encourage these types of behaviors, what channels do you have access to? Email? In-app? Direct mail? The way you reach these people may vary based on your offering and platforms you have access to, but one thing is for sure, you first need to understand the behavior and characteristics of the users that ARE taking your most desirable actions - and then try to map that into getting more people to take those some behaviors. 

This is always tough, for Trello this was trello.com/templates, it's something we had thought about doing for a long time but we didn't want to be overly prescriptive about how people should use our product. That being said, we got a lot of inquiries about templates - and a LOT of other tools provided templates - so it became something that felt like we should consider adding. Like I've said in a few other answers, I think the best way to convince internal stakeholders that something should be a priority is with data. Again, this can be a combo of showing that a feature is table-stakes amongst the area your product plays in, but something even more impactful is collecting feedback from support tickets, data you've gleaned from analyzing user behavior, tests you've run by sharing certain types of content our blog or through your email program that have led to higher engagement. Anything you have that can be an indicator of why a feature you may be advocating for could benefit your users and the company. The other piece of this is figuring out how your product can do it differently. For Trello, when we decided to add templates we knew we needed to do it in a way that would be helpful for our users and also highlight the uniqueness of Trello use cases. That's why we decided to build a community-focused platform that would allow users to submit templates and highlight their stories in an easily digestible format. We wanted our templates to be less about highlighting our product and more about highlighting how the Trello community finds interesting, unique, and helpful ways to get things done - and share that back with the community at large. Timing is also an essential consideration, part of why templates made sense to launch when they did was about what else we could build to serve our users' needs at the time. We bundled the gallery with the actual ability for users to create their own template boards internally for team usage, along with card templates, updates to automation, and more. The importance of timing cannot be overstated enough. Just because a feature isn't a priority at the moment doesn't mean it never will be - stay on it and collect evidence to build your case!

Great question and I've thought about this a lot, I LOVE watching Product Managers work and think that the problems they tackle are super fascinating, that being said, I'm a marketer at heart. I think PMMs are lucky to be in a position where we get to work super closely with PMs but our jobs are very different. I like Product Marketing because it's so versatile, what I do from day-to-day can really vary but I also get to really own things and take them from start to finish, collaborating with tons of people along the way. Product Marketing to me is the "connector" role, your job requires interfacing with so many different teams and people and that is what makes it so exciting to me. PMs are in the nitty-gritty a lot, and for me personally, I prefer looking at the big picture and zooming in on the details but not spending my entire day focusing on one particular thing.

I definitely think the process when it comes to PMM life is very important. Especially for things like GTMs. One of my team's go-to resources is the Confluence Messaging House Template - I like this one because it really is essential for getting everyone on the same page about a product or feature. This is the kind of thing that takes some leg work upfront but pays massive dividends down the line. It helps keep everyone who works on the product or feature – writers, designers, events and sales teams, and everyone else aligned in terms of messaging. The other two templates/process docs my team definitely relies heavily on are the Confluence Product Launch Template and the Trello Go To Market Strategy Template. You can think of these as pairing really well together - the Confluence one is a great place to do a higher level breakdown of the what/why/who/how of your launch - the Trello template is the place where work happens, you can track progress towards the launch and easily collaborate across your team.

As stated above, PMM wears so many hats it's important to recognize what is needed at any stage of a company. When first coming into an organization as the first PMM I think the most important thing to do is establish what does and doesn't exist. I think this is the right order of things that should happen first but if you come into an organization and feel that some of these things are already in a good place you can skip to the next step. That being said, when you are new to a company you have a fresh and unbiased perspective that only lasts for a few months - use those fresh eyes to your advantage! Write down all of your thoughts and learnings so you can look back at them later. 1. Interview internal stakeholders 2. Interview end-users 3. Competitive analysis 4. Align on and/or tweak the positioning 5. Sales enablement 6. Design GTM plans

I think there is a ton of value in having these teams work closely but separated into specific pods. As you noted, there are different skillsets here and they can be even more effective when given the space to own their domain expertise. That being said I think when PMM and Brand get too far from each other the end results suffer. I often think of PMM & Brand like a zipper in that they are stronger together and work in tandem. It's essential that brand messaging aligns with the product experience and that launches are appropriately timed and presented in the market. For all of these reasons, I am a fan of having these teams ladder up to the same marketing leader but for they also to be split into separate smaller teams/pods for ownership and skill alignment. 

Some of the best prioritization I've seen and been a part of is based on the ICE framework: * Impact: what do we think this feature will do for our user-base, our metrics, our bottom-line. This is also a place to consider the size of the opportunity, is it going to impact your whole userbase or a small subset of users? Is this a longer-term feature or a quick fix? * Confidence: how sure are we of this, do we have the right data to back it up, can we test it? I'm going to sound like a broken record but again, bring the data or go out and get it, especially anecdotes from conversations you've had with real users! These mean more than pretty much anything. That being said, the competitive intel is also something that PMMs are looked to fold in. We are best positioned to understand market trends and higher-level positioning of features in the market. This can all help with building confidence in deciding which features to prioritize. * Ease: how difficult will this be to build, market, sell? Thinking about the ease at every level is helpful here, again if a feature is not hard to build but impossible to market then that's a conversation to have with your product and sales teams. You score each of the above on a scale from 1-10 and then add up what you get. This total can be compared to other features you are considering building, and be ranked accordingly. The idea is that the three areas should balance one another out, for example - something may be really high in Ease, maybe it's relatively simple to build, but if Confidence is low or you think the Impact will be small, that will drop the score significantly and create space for a conversation about priorities!