Emily Ritter

We aspire to do this with absolute excellence -- with rapid A/B testing and optimization. Come join our team!! That being said, here are some observations (I polled folks on my team to contribute based on what they've seen in their careers as well). Bottom line, pricing projects are hard--and can be messy! Pricing is all about balancing tensions. You might have the most perfect spreadsheet pricing model in the world. It might even be the best deal for your customers. But if it’s too much work to understand, you’ll probably lose. Here’s some examples: Tension between grandfathering existing customers and serving new customers. Ask how do you be thoughtful about the people who helped you get to where you are today and what do you need now to be successful in the future? It’s important to talk through with cross-functional stakeholders (and make the space and time for it). Tension between simplicity and revenue maximization. Tension between what you want to sell and what people are looking to buy. Don’t confuse your company vision with what people want. Understand the competitive landscape. Pricing differently can be effective (ie transparency in a market historically opaque). But, it can also create cognitive overload (especially with professional buyers) especially when people are comparison shopping. When you’re charging by usage and everyone else is charging by seats, that might work super well, or create mass confusion. Good to explore the pros and cons - and really get to know your customers--both current and future. It’s harder to forecast usage than headcount, so that may create friction in your sales process. To mitigate some of the above: build hypotheses and test them with customers before going live. If you’ve got the budget to survey non customers, go get yourself some data points! Conjoint analysis can be a good way to get a sense ahead of time. Van Westendorp can be helpful (if not done in isolation). If you’ve got a sales team, really leverage them. They often know really how customer are evaluating you and the competition. Betas can also be a good time to test pricing and get feedback. Be flexible, you might not nail it right off the bat.

Yes! We have a tiered launch playbook system that enables us to provide transparency to our product management partners about the activities we do depending on the size and complexity of the feature launch. Big fan of the book "The Checklist Manifesto" by Atul Gawande. Templates can take some of the pressure off of remembering all the small details, especially when you're a little tired leading up to the big day! BUT! Don't over-rely on templates. Solve for the customer not the template.

Small: tight, thoughtful FAQs. Keep it simple. Prep a concise one-pager that delivers the facts and moves on. Large: think about enablement as a mini bootcamp program rather than a one-and done. Work with managers in advance to get their input on what their teams might need. Do in-person trainings with role playing exercises that help confirm learning. Create a temporary slack channel for launch questions (also helpful for reporting bugs :wink: ). Make sure they know how this compares to the competition and what angles make you win. Follow up after the launch to get feedback on the training so you can do even better the next time.

* not getting involved in the product development process early enough * not talking to customers directly * not asking “how might this NOT work out” aka a "Pre-Mortem" (and developing mitigation plans accordingly) * not spending enough time thinking about a “day 2” strategy * being too precious about messaging - test it! A great way to validate messaging is with sales - they can be a secret weapon as they’re essentially testing messaging all day every day on their own.

It really depends on what stage your company is at, how your customers consume information from your company, your ship cadence, and what you’re trying to accomplish with the launches. If you’re early stage, your audience is B2B, highly engaged, it might make more sense to communicate smaller upgrades more regularly. It shows momentum and drives engagement. If you’re later stage and shipping stuff all the time, a big quarterly launch might be more about tying a bunch of features together into a story that lands more effectively, and could help you open up market share opportunities if packaged properly. It might be worth talking with your CMO about the metrics she’s trying to move, perception she’s trying to change, or story she’s trying to bring to life. Starting with first principles might help y’all determine together if a quarterly launch is the best tool for the job.

Great answers all around. Here's what I'd add: * You deliver a product/feature that people actually want * You position your product in a way that gets the right people to try it (which they then adopt because of pt 1) * You deliver against whatever higher level objective you’re trying to achieve for your company (increased ACV, capture new market share, increase conversion rate within current market, etc) BONUS: you learn something you can apply to whatever you launch next PS note on pt 1: you’re less likely to deliver on this unless you’re working upstream and sharing market insights with your product team. Great product marketing influences roadmap, which leads to great launches.

A bit of an “it depends” answer. Sometimes people use betas for QA: does the feature we built work end-to-end? Other times betas can help you determine if you’ve hit product-market fit with your product. And everything in between. It’s best to get super aligned cross-functionally at the KICKOFF (or early in the development process) about how alphas and betas fit into the overall timeline, project strategy, and what the objectives and go/no-go decision are up front. Determining all that at the beginning will help you appropriately time the beta, get the learnings you need, and still hit a GA milestone on time. It also helps the team be more objective about success when the beta is actually live. When you can work with a product team to include messaging or feature on boarding in the beta, you can usually learn a ton! Especially when paired with some sort of survey or user interviews (depending on your audience size) for both people who did and didn’t engage fully with the feature. You can use that info to determine it’s a functionality issue or messaging issue before letting your messaging rip to zillions of people. If a beta is short and the product isn’t likely to change a lot before production, you can still do surveys or interviews to learn about product functionality and “see around corners” that can help you as you develop sales enablement content (ie a more fleshed out FAQ). Sometimes you’ll learn from a beta that it’s best to rollout the functionality but not do any proactive product announcements around it. Have a success or sales team sell a (more limited) feature when needed, but wait until you really nail a use case (ie more dev time) before announcing it more widely.

It’s a good idea to get super aligned early in the product development lifecycle about what success looks like and what everyone really cares about. Get to know your stakeholders as humans. With these insights, you’ll be able to anticipate needs and gain trust. Over communicate, and have fun! Create a “voice of the prospect” and/or “voice of the customer” program that allows you to proactively share market insights that allow you to influence product roadmap decisions.

The heyday of product launch PR is behind us. Ah, the good ol’ days. ;) These days you need truly innovative product stories and/or proven business impact to get solid coverage. Customer or human interest stories can help, as can data-driven storytelling. Think about how to use PR in these ways post launch, especially if your product or feature isn’t particularly newsworthy on its own. It’s hard to rely PR for any but the biggest brands, but professional audiences are more reachable through trade press. So we find that as we're targeting or influencing a professional audience, launch PR can help get awareness or can help sales teams close the sale. But it can't be in a vacuum -- it needs to be reinforced by other touchpoints. That’s because PR will typically drive a spike of interest (aka traffic) and launch day conversions. Be prepared for that to drop-off pretty quickly. Because of the spikiness of PR, you’ll want to be prepared with day-two and engagement strategies regardless. Then, PR becomes the icing on the cake!

Ultimately you’re working to drive revenue (in one way or another), which comes from feature awareness and/or usage. Revenue is a lagging indicator so your launch plan should include metrics that can ladder up to revenue and be measured in a more immediate time frame. * Some measure of awareness - page visits on launch day (and subsequent time period) can be one measure * Some measure of conversion - depends on where the feature impacts your funnel. If it’s a entirely net new product, hand raisers on your landing page might be this conversion metric. Trial starts, or first time use might be others. * Close Rate, Pipeline, and Contract Value might be other key metrics that ladder up to revenue. Within a quarter I want to see organic interest (either from customer base or market expansion) - ie opportunity creation!