Gregg Miller

30 days: Balance being an absolute sponge and learning by doing. Be a sponge by reading every doc you can get your hands on (enablement materials, case studies, team quarterly/annual plans, research studies, etc.), talking to as many prospects and customers as possible, and scheduling 1:1s with both stakeholders and company leadership. Learn by doing by getting involved in low-risk, low-hanging fruit activities where a PMM touch is needed but perhaps don’t require a ton of context. 60 days: Hopefully you’ve gained enough context by 30 days to start to get an idea of what the big challenges and opportunities are at the company. My goal is to have identified a couple of “base hits” that I can deliver by days 60-90 that can demonstrate tangible results against things that a key stakeholder cares about like the CMO, a Sales VP, or a product manager/leader who is a respected influencer within the product org. Identifying and delivering these base hits gives you an early platform within the organization of visible results and relationships that can open doors and give you the room you need to set an ambitious vision and plan for the function. 90 days: Delivering a POV on both the role you want to carve out for the PMM function (see my answer on surprises about moving to a smaller organization) and the initiatives you hope to tackle in the coming quarter. If you’ve done the homework of gaining context as a sponge, delivering one or two meaningful base hits, and winning the trust and endorsement of a couple influential stakeholders, you’re much more likely to get buy-in on your plan/POV and the latitude to actually start getting to work on building the PMM function as opposed to just executing on stuff people throw your way.

There’s two main drivers I think about with respect to org structure. Important caveat on the below being I primarily have worked at smaller organizations where org structures across the company are often highly nimble. 1. How established the function is - When the PMM function is new, oftentimes you might be the only Product Marketer or have just one report. In that scenario I think it’s important to keep yourself and your report as generalists and prioritize the most important projects across the business as opposed to specializing by product/persona/etc. This enables you to learn the business much faster and build a lot of credibility by adding value on the most pressing opportunities — both essential precursors to being able to figure out the longer-term org structure and advocate for growing your team since you know where the need is. As the function becomes more established, I like to add in a Market/Customer Insights function within PMM and start aligning the rest of the team around business strategy. 2. Business strategy - Org structure should reflect the direction the business is going, not the other way around (this is true outside of PMM, too!). Sometimes that means I’ll have one PMM staffed to each core product, other times it might be audience focused (e.g. SMB vs. ENT; partners vs. customers), and still other times it might be based on a strategic priority like expanding into a new self-serve transaction GTM channel. I’ll also be clear with my team or candidates I’m interviewing how the competencies required differ based on which part of the business strategy they align against where there might be more or less focus on things like upstream market opportunity validation vs. messaging and launches vs. growth marketing.

At Zapier I approached this by starting with a mission statement to describe why our team exists and the work we aim to uniquely do for the company: “PMM exists to maximize Zapier’s market opportunities by (1) clarifying where we win and (2) driving GTM strategy for product success.” I then defined responsibilities that align to (1) like TAM, market segmentation, personas, positioning, competitive analysis, etc. and separately to (2) like working with Product validate market opportunities, designing and executing betas that ensure product/market fit, and of course planning and executing launches. Lastly, I made sure to socialize this charter around the org to ensure awareness and buy-in that this was the direction we were heading as a team. This is a very different scope from what PMM was doing when I joined — I often talk about it as charting a course from PMM 1.0 to PMM 2.0 with the expectation that getting to the full potential of PMM 2.0 will take quarters if not years. Thus when it comes to prioritization, I’m always asking myself “where do I see a combination of ripe business context, willing partners/stakeholders, and PMM team capacity for us to tackle an initiative that will take us more in the direction of PMM 2.0?” This requires hard prioritization conversations with stakeholder teams where we say no to some requests that come in in order to create the space for the bigger, more strategic efforts that pay long-term dividends. But without those tough conversations, the team wouldn’t ever get to PMM 2.0.

I’m assuming this question is about moving from a focus on the “last mile” of the go-to-market process entailing sales enablement and product launches to more “upstream” go-to-market strategy activities like identifying market opportunities, defining target segments in the market, partnering with product earlier in the development process, etc. There are many ways to navigate this transition, but a fairly common thread I’ve seen enabling those various paths is insights — insights on customers, competitors, or the market. Your task as a PMM leader is to “earn the right” to participate in those “upstream” activities by demonstrating your team can add value and be a thought leader in those conversations. Start small with things like win/loss analysis, customers interviews, or mystery shopper exercises with your competitors. You can take things a step further by launching a customer advisory board, especially if you’re in enterprise SaaS where it’s challenging to generate quant insights given the small audience of buyers you’re targeting so qual insights from a council of customers can be game-changing for getting feedback on your company’s product roadmap, messaging, or other forward-looking plans. And if you want to be really ambitious, you can formally establish an insights function within your team so that you have the resources to constantly produce a steady stream of insights that give your team a really strong seat at the table as the voice of market/voice of the customer. This last route of an insights function could take numerous forms with two potential examples being dedicating 50% of one PMM's time toward insights exploration or hiring a dedicated Market Researcher.

One of the biggest surprises is that the vast majority of people at smaller companies have little idea of what product marketing is. Your new colleagues may have never worked directly — or even indirectly — with product marketers before. This means that you as the new head of PMM have a much bigger leadership challenge ahead of you than when working at a larger company that likely has had a fairly defined PMM function for years. Further complicating the challenge is that product marketing looks so different at so many different organizations. It’s super important to meet this challenge head on by proactively answering questions like: * What value do I think product marketing should contribute to this company? Why do we matter? * What is the appropriate balance of tactical vs. strategic and short-term vs. long-term work for my team? * How should we prioritize and manage the myriad projects PMM could potentially lead (i.e. sales enablement vs. market segmentation vs. market opportunity exploration/validation vs...) * What tools, frameworks, and processes can help my team work successfully cross-functionally? * How should all of the above evolve as both the team and the organization grow? It’s tempting to just dive into the work, but I’ve found it to be super helpful to explicitly define these types of questions and get the buy-in of both leadership and cross-functional leaders on my team’s scope. Given how fluid/undefined PMM can be, taking these steps gives you a better shot of being able to sit firmly in the driver’s seat and steer your team’s destiny.

I'll try and answer each of these three questions separately. * My philosophy is short and sweet. If you're making battlecards longer than one page or using size 5 font it's going to be impossible for your sales reps to get the high impact at a glance insight they need. Battle cards work best when they are reference docs a rep can use to find what they're looking for in <30 seconds. If they get lost in the amount of detail you provided, they will not use the battle card after the first attempt. * If you don't know the technical components and there's no way for you to learn them via kicking off a project to do so, the best thing you can do is shift the story. PMM's value to the business is about being able to find the most compelling story possible within the limitations of available information and the market situation. What do I mean by shift the story? Don't compete with your competitor on their terms. Figure out where you do better -- a certain type of customer, a specific use case, a level of service you provide, a brand identity that resonates with the market you're targeting, etc. * You ALWAYS have enough to guide sales in some manner. Per my answer to (2) above, PMMs are masters of the story. Sometimes your story will be stronger than others, but some story is better than no story. Work with sales to set expectations on what is realistic given whatever limitations you're facing and test your early drafts with top reps and managers to get feedback on how to improve.

GTM kickoff meeting: It is absolutely essential to get all the right stakeholders in the same room to get on the same page around what we're doing, why, by when, and with which owners. I like to have my team run these meetings roughly three months before a given launch and use them as an opportunity to share out a preliminary GTM strategy they've developed in partnership with the product manager. The goal of the meeting is to provide a concrete rough draft detailing strategy and assets and timeline and owners for everyone in the room to pressure test and improve upon. It should be a collaborative discussion that brings out the best thinking of everyone there and then develop the right set of next steps. Launch tiering philosophy: Not all product releases are created equal -- or more aptly, will have similar value for customers/the business. You will quickly tire out your external audiences and your internal teams if you are always shouting full volume about everything that ships. Having an agreed upon system for classifying upcoming releases as small/medium/large is a fantastic way to align on level of effort and importance for a given release and ensure all teams are investing the right amount of effort. Asana or similar tool: There's a lot of moving pieces in a launch. Trying to keep it all coordinated in a basic Google Sheet or word doc is just too brittle. I find that tools like Asana really shine when it comes to product launches as they combine timeline visualization, task ownership, commenting and communication, etc. all in one place and in a way that is much easier to manage/stay on top of. Retrospectives: Too often teams focus on the launch itself and shipping the thing and don't have an intellectually honest conversation after the fact to ask "did it work, and if not, how are we going to either improve results or avoid similar mistakes in the future?" These can be hard conversations to have as folks have invested a ton of energy into building and launching the product, but without them a company risks defining execution as success rather than defining the desired business outcome as success.

This will vary depending on how important a given product is as well as its degree of complexity, but for a decently robust feature/product I think you'd want some of the following as a minimum. [Internal] Product one-pager: Succinct asset that explains what customer pain points we're solving for, what the product does/how it solves them, the value prop and top benefits of the product, how it's different from what competitors have, the pricing and packaging guidelines, and any other product-specific reference information your sales team would find helpful. Proof points and testimonials: Your prospects want to feel confident that this product works and works for people solving the same problem. If you have any data on the efficacy or ROI of the product, make sure your reps know it! Same goes for customer testimonials -- see if you can get some great soundbytes from participants in the pre-launch product beta that can help de-risk this product for an uncertain prospect. Collateral: Your reps need a visual asset that helps them speak to the product and helps the prospect have a reference asset that they can use to refresh their memeory on the value/how it works after the sales conversation is over. This is doubly important if the prospect needs to champion your product to other internal decision-makers. Help them tell the story. Product demo: Either a recorded asset or a talk track. This should really focus on the pain points, value prop, and how the product works to deliver that value prop. It's important to keep the "how this works" part as focused as you can on the value prop and ideally the overall demo on the shorter side so that you don't lose people's attention/they get lost in features instead of what value the solution delivers. FAQ/objection handling: Use a beta to understand what types of questions, concerns, and objections come up from someone being introduced to the product for the first time. Then create a simple reference resource that preemptively addresses them; make sure to continue updating this after the launch as you continue to get more feedback from the market.

In an ideal world product and product marketing should be embedded in one another’s efforts from start to finish (see my other response on “customer needs” and getting PMM further upstream). In this world product marketing has played an active role in helping set the vision for the feature, doing research to support its validation/market opportunity, and coordinating the launch priority (e.g. is this a “nice to have” vs. a tentpole launch). In such a scenario it can often be appropriate for product and product marketing to sign up for shared KPI targets on things like free trials, signups, active engagement in first 30 days, 3-month retention, etc. However, many teams are still working toward that ideal world. If the product team only involves the product marketing team at the very end of the product development process as “the team I go to when my feature is ready to launch” then it might make more sense for the product team to own much more of the adoption KPIs. Why? Because in this scenario PMMs have very little latitude with the tools at their disposal like messaging and launch tactics since many of the core decisions around the value prop and target audience — which ultimately play a huge role in product/market fit and therefore adoption — have already been made.

There's a lot that goes into effectively measuring success. * Defining what success looks like ahead of time (e.g. what KPIs you're trying to influence) * Recognizing that the definition of success will look very different depending on the initiative (e.g. a messaging overhaul of an intro proposal might have % of reps passing certification as a KPI while a product launch might have attach rate as a KPI) * Making sure you have a means of measuring that KPI (e.g. closed/won opportunities in Salesforce; auditing a random sampling of customer calls). Success measurement can frequently break down because the definition of success is determined post hoc rather than before the initiative was developed; there are gaps in data systems; or teams haven't set aside sufficient time and resources to get in the weeds of measurement.