Christina Dam

Great question and I would be very curious to hear how other companies do this! I mentioned in an earlier question that Square is very collaborative, and that means there is a mix of formal, and informal, ways in which we deliver customer feedback. Formal research / customer feedback studies: * PMM often captures customer feedback through conducting surveys, commissioning external research, listening to calls from Sales or Account Management/Customer Success, analyzing dashboards, or conducting interviews ourselves. * When we conduct these more formal studies, we always produce a Google Doc that summarizes the project objectives, goals and approach, and key findings (in addition to a link to all the raw data & feedback). * PMMs can provide immense value by taking the time to distill the insights into an executive summary, and articulate the prevalence of a specific piece/theme of feedback, and the impact it could have if addressed (e.g. will more customers adopt the product, vs. will it help with engagement or retention, etc). * In order to highlight this added strategic perspective, I haven’t found anything more effective than a well-written doc that the product teams can read and comment on. More informal ways of delivering feedback: * We host regular meetings with our Sales, Account Management and Customer Success representatives where they can surface individual customer stories and feedback directly to both PMs and PMMs. * We also utilize slack channels heavily, where PMMs and other functions can share customer feedback directly with our product managers, as we hear it. While many of these ‘one-off’ stories re-inforce feedback that has already been heard before, they provide additional insight into use cases or nuances that may not have been fully understood before. Top Tools used for delivering customer feedback: 1. Google Docs & Sheets - to summarize customer feedback, which can be translated into spreadsheets that Product Managers can use to further assess and prioritize the requests. 2. Salesforce is used by our Sales/AM teams to log feature requests, with dashboards we can access to pull top requests. 3. Gong - We also utilize Gong to listen to calls from our Sales/AM teams, and will often include links to the recordings in write-ups. And finally, I’ll mention the importance of repetition in delivering customer feedback. A well-written report may be appreciated and digested, but a PMM will gain even more trust as the voice of the customer if they are also referencing those key insights and speaking knowingly about the customer use cases in live discussions, product design reviews, roadmap planning sessions and more.

This is a great question and a situation that many PMMs will find themselves in at some point in time! A few thoughts here: 1. Building trust takes time: Before you can be seen as a strategic partner, you need to build trust with the team and demonstrate you know and understand what they are trying to achieve. As quickly as you can, become an expert in the product, and your customers. You need to know both of them inside out in order to do the work to connect the amazing product being built to the audience you believe most needs & would best benefit from it. Don’t wait for someone to show you - dig in and set up demo accounts, schedule calls with customers, research the industry, and ask to join roadmap reviews / design reviews / sprint planning sessions / team retros. 2. Show your value. While you’re learning the product, the customers, and the team, you’ll probably uncover work that isn’t being done, or is missing. Go do that work! Find some white space where you can both be proactive and add value to the overall mission at hand. Share what you’re doing, why you think it’s important, and the results. Do this over and over again -- explaining WHY is incredibly powerful, as is showing the impact of your work (can be metric-driven or new insights, etc). As you deliver key insights about the audience, and offer opinions on what features you think might be most important to invest in (and why), and how you can capitalize it for the business, your value will become understood. 3. Educate, educate, educate. Product marketing as we know it today is a relatively new function. There will always be someone you work with that has had little exposure or experience with PMMs. It is probably useful to have a few slides in your back pocket that explain “what is product marketing” and “how to work with PMMs” that you can share with teams (over and over again!). Be sure to include the part about product marketers being key inputs into product strategy and roadmaps, too :-).

I like to think of Product Marketers as co-owners of their product(s). It is PMM’s responsibility, alongside Product Management, to build a successful product and drive key business metrics. With this framing comes a responsibility for PMMs to own the success of a product not just at its initial launch, but throughout its lifespan to drive product satisfaction, retention, loyalty and advocacy from customers. This makes our role in communicating ongoing changes to the product really critical, as it’s extremely rare that you’ll launch a ‘perfect product’ on day one. There will always be changes! And just like at the initial launch, a PMM should be defining the Go To Market strategy for post-launch releases as well. Does this mean that every feature update or product change needs a full GTM plan? No. But does it mean that for every feature update or product change, a PMM should have an opinion on why (or why not) it should be communicated, and to what extent? Yes. Questions that can help shape the feature release plan include: * Is this a bug fix or usability issue that will be noticed/appreciated by existing customers, but not meaningful for non-customers? * Is it self-explanatory or will customers need some education on how to utilize the change? * Does it directly address a pain point / top churn reason? * Or is this net new functionality that could expand the addressable audience of the product? Questions like these help you hone in on the target audience for the change (existing vs. potential customers), and scope of impact, all of which can guide your GTM recommendations. In the case of re-introducing a product to a winback audience, I would typically focus the messaging on what is new and how the offering has changed, and be really targeted to this audience. These audiences can be difficult to convert, but when the reasons they were dissatisfied are directly addressed, I do think these are great opportunities to try and re-engage them -- just make sure you do it when you really have a new and improved story to tell!

Assuming product(s) are being built to grow and last the test of time, there should always be a balance of building for short-term vs. long-term impact. The exact balance between those two can vary depending on the vision and goals of the business. In my experience, we spend the most time discussing and aligning on short- vs. long-term investments during the Annual Planning cycles, which at Square happen once a year. During this time we take a step back to restate our Vision for the solutions we are building (which is a 3-5 year view), and identify strategic priorities that we believe will help us move in that direction in the next year, and the metrics we’ll use to measure progress. This gives us space to explore how we build value over the longer term, either by expanding to different audience segments (TAM expansion), increasing customer value and retention (LTV, ARPU), or introducing new products (just a few examples!). Knowing that we typically have these discussions about product strategy and future direction during Annual Planning, it allows our PMM team time to prepare our perspectives and spend earlier parts of the year conducting research, deep diving on competitive and market trends, and shaping perspectives and business cases around what we think will set up the product / business for longer-term success. If your company doesn’t have a formal planning period, I believe PMMs can still proactively take on the work of thinking about the future and longer-term growth strategies. Similarly, if there isn’t a shared vision that PMM and Product are working towards, then that would be a great place to start collaborating and aligning!

My first piece of advice is to reframe ‘conflicting voices’ as different perspectives. When you think about it as different perspectives, it removes the negative connotations associated with conflict, and can be easier to dig into the perspectives themselves (vs. getting caught up in the discomfort of disagreement). Sure it would be easier if everyone’s perspective was the same or in agreement, but it would probably also mean you weren’t thinking exhaustively about a problem you were trying to solve. I have found that typically when these groups have very different perspectives, it usually comes down to either: 1. lack of shared understanding (about the customer or product), 2. lack of complete understanding (e.g. they only see part of the picture), or 3. misalignment of goals across teams (each team is working towards something else) The first thing I do as a PMM in the center of all of these teams (and others!) is to try to understand each of their perspectives and why they have that particular opinion. Once I compile them all together, it’s often easier to see the reasons behind divergence. If it’s a situation where alignment is required (e.g. defining a target audience, for example!), I always try to lead with driving for a shared understanding of the customer first, and a re-stating of the goals. This often unlocks the debate, and allows teams to see a more complete perspective. Then you can move into decision-making. By bringing stakeholders into the decision-making process, and anchoring recommendations on 1/ which decision best suits the customers’ interests and needs?, followed by 2/ which decision best suits the needs of the business, it helps all teams feel a part of the solution and can drive greater support and buy-in on the decisions.

At Square, the product development functions all work really collaboratively and share a customer-driven approach. This means that product designers, product managers and product marketers are all providing data and insights about the audience, and then collaborate on product/feature discovery to ensure alignment on the problem we’re trying to solve (which typically all ends up in the PRD). This helps ensure that design starts with a bounty of insights and learnings, which is then supported with testing through development. This can either be in the form of usertesting interviews to get feedback on new designs or workflows, feedback captured during alpha or beta from customers, or a live A/B test at launch.

This is a great question and one that unfortunately can happen quite often. Whether it’s sales training or another aspect of the GTM plan, it can be challenging to get all the timelines to sync up -- especially if the PMM hasn’t been looped in early enough to prepare the GTM plan and deliverables. In this type of situation, I first like to remind the product/eng team that if Sales doesn’t understand the features they build, they can’t sell them and/or help ensure that customers are educated and trained on how to use them. No developer wants to see their work go unused by the intended audience, so it is usually in everyone’s interest to make sure all aspects of the GTM plan (including Sales training) can take place. Help build an understanding of why it’s important for training to take place, and seek to understand the downside on their end of waiting, in the hopes of coming to a timing compromise. There may be instances where you can also re-assess how critical sales training is to an initial rollout. Is this a feature that’s really critical to new customer adoption? If yes, then you’d want them trained ASAP for the launch. If it’s a nice addition but not the top value prop, perhaps Sales Training can come post-launch. Even in the best situations it’s very common for a PMM to have to adjust their ‘ideal’ GTM Plan as launch gets close, so flexibility and problem solving at this stage is also key.