I want to know how to get my product team to support efforts outline the desired product benefits, so we can discuss a marketing plan earlier in the process. I'd also like advice on how to let them know, in as kind a way as possible, that some improvements/repairs should probably not be launched because it's the natural progression of our product's capabilities.

PART 1: DOCUMENTING AND TESTING PRODUCT BENEFITS  

The product's team job is to lay out the Minimum Viable Product and the ideal scenario and technology of what's available. A strong product marketer can take the minimum product specifications, speak to potential customers and figure out which product benefits resonate most with them, then build the marketing plan from there. If you're having problems getting the main idea, show them the benefits of a prototype and how it can help shape their product vision. Understand the WHY there is an issue in getting the product benefits so you can adjust and help the product team accelerate. 

ex) In some of less-resourced smaller products where we didn't get prototyping support or documentation, we called in a favor with a UX person who was a whiz in Keynote to show the product flow, then I road-tested it with some sales teams and customers, got our main value props and build an idea of positioning from there. In the past, I've had my product marketing team take on the heavier lift of documentation on details when we need to ensure we have the latest information. Sometimes have to be scrappy to get the job done. 

PART 2: GO OR NO GO ON LAUNCH 

As for not launching some features/improvements or repairs, or any time you're trying to influence a product team you need customer feedback and data on why the customer isn't ready. The product, especially a software product, will never really be fully "ready." So you're conducting more of a trade-off, calculated risk discussion. This framework is one that I recently came across that I'm stealing because it operationalizes what we do on launch decisions and timing. 

DURABLE DECISION FRAMEWORK 
- Goals: Why are we doing this?
- Assumptions: What facts, constraints, and projections are we assuming?
- Options: What are the different choices? What are the pros and cons?
- Decider: Who is responsible for making the decision?

Most of these decisions the product marketer is not the decider, but your role is to complete a very thorough understanding of the customer, the market and the product state to understand the trade-offs. Build them options vs trying to convince them of one avenue and you'll build a stronger relationship, and you may brainstorm something even stronger.

For example: Our team had to make a decision to launch a major product during the heights of COVID-19 and a lot of noise in the industry. Our main PMM on the project built a decision/trade-off framework and then we aligned on the right date with the fewest risks. That type of alignment takes more time, but results in a team that's better aligned against the full picture of the launch risks and can build better plans to mitigate and deliver a strong product to market. 

This looks like 2 questions, but it goes back to your relationship with product managers - you need to make sure they bring you into the process very early on when they are prototyping the feature/product. You want to understand what they are trying to solve, so you can align on what the GTM could look like. You also need to have an honest discussion on why they think these small enhancements deserve a big push if you believe they don't need a bigger GTM. It goes back to the t-shirt sizing exercise - what is the feature/product value, is this driving new adoption, is this driving your exisiting customers, are you competing with competitors, etc. You need to ask all of these questions to really understand what success looks like.  

On your second question - I started remotely at Shopify and it was definitely a drastic change from being in an office in previous positions. Back-to-back meetings behind a screen can be draining, so my advice is to switch up the way you participate in them. I like to take walks while I meet with people for a change of scenery, or even opt for async video recording updates, occasionally—I leave video notes for my team or my boss all the time and it just makes it easy to communicate your thoughts. You can also communicate your tone genuinely this way. Also, sometimes I like to opt for voice-only instead of video chat. I find that this takes some of the pressure off communicating face-to-face and allows for a more free flow of thoughts and speech.

I'll start with the first question around working with your PM team to get a sense of what's launching and product benefits. If your product team does not already do this, definitely work with them to see if they can develop a PRD or some form of product documentation that outlines the problem the product is trying to solve and what the solution will be. Here's an example I found quickly on Coda: https://coda.io/@john/prd. This is an important asset that all stakeholders across engineering, design, and PMM can reference. In terms of outlining product benefits - your PM counterpart may lean on you as the PMM to define the benefits, but they should ideally have a sense of the customer problem they're trying to solve with a particular feature if it's on the roadmap.

With regard to not needing to launch improvements/bug fixes - one thing you can do that I have found helpful is establishing a framework for launch tiers. Low customer impact items like minor bug fixes, as an example, would be tiered in a way that would indicate no marketing support. At my company, the launches that get marketing support are typically Tier 1 and Tier 2 launches, and a bug fix would be a Tier N/A (no support). The tiering is based the level of impact to customers & prospects. You can work with your product team to align on the tiering framework and define tiers for every launch so everyone is on the same page.

If there is one thing I've learned in my time at Intercom it is to ALWAYS start with the problem statement. This is ingrained deeply into how we solve problems, and it really stems from how our product team builds product. At the core, never start with the solution - always start by outlining the problem you are trying to solve.

My colleague Robbie does a great job of explaining this philosophy here. The main takeaways are:
1. Define the outcome the customer wants
2. Define why they want that outcome
3. What's wrong with how they are currently solving this problem

It might be helpful to suggest such frameworks to your product team, and this should also help in informing how you build your marketing plan (identifying customer pain points, the audience, etc). This framework could also help in the last point you make as well, around suggestion to NOT do some launches. WIthout clear problems-to-be-solved, it makes it easier to suggest to not do something.

As far as working remotely, don't be afraid to share thoughts in working docs, and allow space for working asynchronously.