Our product team ships feature updates incrementally, how would you decide the scope of each of the feature changes? Do you market each of the feature updates as when they come out, or group them together? Thank you!

I would put yourself in the shoes of your customers and decide whether the feature update matters to them (or not). You can consider different channels/formats that better highlight the more significant ones and others where you keep customers informed but might be more trivial.  

Sometimes, no update is fine too if there’s no material impact. People do appreciate it when companies don’t inundate them with every little update. If all the features ladder up to a broader theme, you can consider grouping them together in a larger update so that customers can see the big picture.

In organizations where you have a product machine that pushes new features or feature enhancements every two weeks or so, I highly recommend creating a GTM launch engine that can optimize to get the biggest bang for your buck! Having done this in several organizations, I start with partnering with our product and marketing teams (plus, GTM like Sales or CS if a B2B product) to identify the criteria for stack ranking product releases. The ranking would sort and “tier” or size release by things like business impact, differentiation, new vs enhancement, and price/packaging as relevant. You can also start with a 2x2 framework on business impact and differentiation to start guiding your GTM launch tiers–we do this successfully at Glassdoor today!

Ideally, if you have a marketing calendar and overarching stories you hope to tell over the course of the quarter or year, you can work with your product counterparts to devise a GTM launch plan for one or more than one feature or product set to anchor your narrative.

At my last company we made a launch tiering playbook. It was a series of 6 steps:

1) First, we's look at product's roadmap to see what was on the horizon

2) From there, we'd review PRDs. Mainly, we'd use the PRD to know what was behind the scenes so that we could forecast impact so that we had an idea for meaty vs light features coming. 

3) We'd use that to think about bundling and timing. Some features with like components could work well as a bundle, of which the bundle could carry more weight to customers. Some features could stand alone. This is really about your gut feeling, which is where having a PRD to reference and forecast impact is important. 

4) We'd then tier the launches. We used 5 tiers, but it could also be 3 or 4, depending on what works for your business. Ours were:

• Moments: Flagship launches that open new markets and directly drive revenue
• Milestones: Releases that indirectly drive revenue and unblock deals
• Modernizations: Releases that create new opportunities for multiple personas with less revenue impact than Milestones
• Migrations: Release that drive new ways of working
• Maintenance: Releases that keep the current customer experience up to date

5) From there we'd build a S/M/L bill of materials template. We'd map tiers to a BOM and execute a large bill of materials for Moments vs a small one for Maintenance. (Of course the template is a starting point and each launch should include whats necessary rather than stick to a formula)

6) Then we'd create an escalation process, with documented review criteria. This way, if a PM/stakeholder felt that a launch was too low of a tier, there was a documented way where they could appeal for a higher tier of which we would discuss and adjust as necessary

This way we could manage internal expectations while setting our PMM teams up to do great work as it came to launch moments. 

The biggest challenge for us in implementing this was the PRD requirement. Not all teams at my last company made PRDs for their launches, but it also created an opportunity for us to introduce logic behind what information we needed. To compromise, we were building an intake process where absent a PRD a PM could submit a form (we used Jira) that contained need to know information. Not all PMs are equal when it comes to filling out this info, but it allowed us to make reasonable judgements. And for the PMs that didnt submit thorough information, it was a learning routine for them to see that other PMs who did submit more detailed info could get more weight behind their launches. 

I think if you document a process and explain the reasoning (and have management support backed by business impact to implement the process) then you can create a path to collect the information you need to scope releases and launch appropriately. 

Depending on how broad your product is (does it span multiple categories, are there different aspects of the platform,e tc) and how many products your company offers - you may not have the capacity or there isn’t appetite to market each feature update.

For instance, most of my last 5 roles have included multiple product portfolios, each product area contains at least 5-10 apps. I would NOT market each of these feature updates as they come out because our customers cannot digest that volume of information. This is where Tiering would be beneficial as you can set up a matrix of tiering principles and what level of marketing support you would offer based on the tiers. I have noticed that a lot of newer products may not have a tiering system in place. That’s a great opportunity to define what are the features that you MUST announce, which ones are nice to bundle together and if possible, group the features into categories or themes to make it easier for your customers to consume the information.

When determining if certain features should get more market focus or attention, I typically ask a couple of questions:

1. Does this update include changes that you are legally obligated to inform your customer about (e.g. terms of service or privacy policy changes)
2. Is this update a quality of life improvement? If so, is it enough of an improvement that customers will get excited about it?
3. Will this update require a change in existing customer behaviour? Is so, is that change minor or major?
4. How close is this update to an upcoming one, and how do they compare in terms of how you answered the previous questions?

If you answered yes to to the first question, then absolutely you'll need to communicate the changes to your customers. 

If you answered yes to the second question, but don't think customers will be excited about the change in their quality of life, interaction, or experience they have with your solution, then you can probably keep communications to a minimum. If the update is something you know your customers will benefit from and be excited about knowing, then you'll want to let as many of them know as possible.

If you answered yes to the third question, then you'd be doing your customers (and your business) a disservice by not telling them about it. Behaviour is hard to change, so you'll probably have to tell them more than once.

If you weren't able to answer yes to any of the previous questions, then you can probably sit on the update until a more important one comes down the pipe (unless they are weeks or months apart, then you may need or want to reconsider).