AMA: Atlassian Former Marketing Director (Trello), Jessica Webb on Influencing the Product Roadmap

Over the years we've worked really hard to get PMMs a seat at the table when it comes to working with the predetermined product triad - Engineering Manager, Product Manager, Designer. I've found that building individual relationships with each of these people is key to getting brought in to higher-level conversations from the onset. Besides developing interpersonal relationships I think it's really important to express that you WANT to be a part of the design process, and that doesn't mean you need to be consulted for every little detail, but making sure it's known that you care and have opinions in this area is 🔑. It's also great to bring examples of things you like and don't like and to take a stance on why! I'm lucky to work with designers that are extremely inclusive and really give space for every voice to be heard and for feedback to be incorporated. PMMs have a special skillset and vantage point, we see a lot of competitive collateral and know what's going on in the market - bringing that to a design conversation is usually more than welcomed.

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!

It can be tough to get access to data sometimes depending on how your org or team is setup. Maybe you are small and don't have people dedicated to digging into this, maybe team siloes create too much process or your industry is highly regulated. If that is the case I'd encourage you to go out and get the data yourself - can you test competitor products and write up your findings? Can you have some friends or relatives sign up for your tool and gather feedback? Social listening is another great way to get cursory data - tools like Tweetdeck or SproutSocial can be great for seeing trends in your follower base. I'd argue that some data is better than none and these are good alternative ways to get something. The above is helpful for the shorter-term, for the longer-term I think it is on the PMM to figure out how to get the data they need to help drive decisions and direction. This may mean building a closer relationship with the person or team who owns this area, or it may mean taking a SQL course and becoming the resident data expert yourself.

This is always a bit of a dance, I'd say we've fluctuated over time with being better at sharing things in advance vs. more so communicating a changelog of features we've added over time. In my eyes, this often comes back to who owns this type of communication, and it can sometimes be a bit of a hot potato between PMs and PMMs. The needs for these changes being communicated are also different within our userbase. Understandably, some of our larger-scale clients and admins need to know about changes before they roll-out so that they can plan accordingly. One way we've found is good to communicate about upcoming roadmap changes is to create a section on our blog for product-specific updates - there we share things that are coming, beta programs, and announce new features that are live for everybody. These posts are typically shared in our bi-monthly newsletters that is sent to millions of users each month 💌. To be totally honest I think we've still got room to grow here and I'd love to hear from people who feel like they are doing this really well!

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.

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!

Bringing in information about trends in the market, what competitors are doing, and the most important thing - USER FEEDBACK! I have learned over the years that the best way to get any sort of buy-in for roadmap planning is to come armed with real evidence. This includes existing user anecdotes but it also definitely includes higher-level trends you are seeing in the market. I think PMMs should be utilized as more than just marketers, we should be experts on our users, their needs, and the climate they are working within. Of course, things like naming, positioning, targeting are very important and the backbone of any PMM role, but that being said, if PMMs are not involved at the level of influencing features based on customer feedback - they will have a much harder time later trying to market features. It's easy to get stuck in the weeds of feature building and forget that at the end of the day these features need to serve REAL users. A PMMs job is to keep that vision clear and relay information in both directions, back to the people building the features, and out to the users and teams that at the end of the day will utilize said features! 

One of the biggest things people get wrong when working remotely is accidentally forgetting to create space for human connection. It can be so easy to end up in a very transactional workflow where you only meet to check-in on statuses of projects and to talk about timelines. This can go on for months when all of a sudden you look around and realize your team is burnt out and disconnected. Something that helps me stay connected with all types of teammates, but in this case my PM is making time for a consistent 1-1 meeting. Of course, we tackle work-related convo as well, but we always spend the first portion of it talking about "life stuff" - when you pause to take a moment and remember the human on the other end of the zoom it creates space to work together while also keeping the human connection intact. We've written a ton of great content about how to maintain bonds when working remotely (something Trellists has been doing for many years), one post my coworker Chris wrote has some great tips on Ways To Make Strong Connections As A Remote Worker.

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.

Building relationships with the right stakeholders. If you want to have any influence regarding the product roadmap you need to garner respect from the people who already influence it most. The best way to build those relationships is to create consistent touchpoints and check-ins that don't just happen when you want something :) Think about what you can bring to the table, whether it's competitive intel, customer insights, or general brainstorming - you need to give to get. I see many PMMs make the mistake of only asking for what they need vs. building a symbiotic relationship with the product, engineering, designer, support, and sales teams! It's similar to any other type of relationship, friendship, romantic, or otherwise - no one wants to engage with somebody who only takes and never gives.

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.

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.