How to Stay Sane During a Product Launch

A Simple Framework for Launching (and Managing) Products

If you’ve had the pleasure of watching a gaggle of five year olds play soccer, then – congratulations -you’ve essentially experienced a high-profile product launch.  Let’s run through the similarities: Multiple goals, lots of players, yelling on the field, concerned parents and a lot of folks running around without purpose or direction.  Occasionally, you’ll even get a few players break down into tears.

It doesn’t make sense.  Five year olds have a perfectly sound excuse: They’re five!  Product launches, conversely, are driven by fully formed adults.  So why does this happen?  Why is difficult to wrangle folks and get everyone to build out a plan, execute on that plan and eat their orange slices at halftime (whoops, analogy is falling apart).

If the above sounds foreign to you, consider yourself lucky.  If you’re saying: ‘Nah, not us.  We have a fully-staffed program management department and we all adhere to a framework’, well, to that one reader, this article probably isn't for you.  I’ve seen really great program managers work their magic, herd the cats and still get overwhelmed and overcome by this tidal force of big egos launching big products with big stakes in very little time.

To that end, I’d like to share a very simple model that’s worked for teams I’ve been part of.  In fact, I tend to rely on this model in ongoing product management work too.  By no means will this model serve as a fully fleshed out program plan (there’s no Gannt charts. Sorry Gannt.), but it’ll get the planning off the ground.  If nothing else, it compartmentalizes the work, and sometimes that’s the most difficult part.

On more creative days I’d have a snazzy acronym, but today I’ll call it the “Build-Market-Sell-Support” model.  This model supports cross-functional product management where customer success is reliant on a performant, value-laden product coupled with a positive customer experience.  If nothing else, it’s overly simplistic, and purposely so.

The idea is to look across four different areas in managing a product launch.  How will we build the product?  How will we market the product?  How do we sell the product?  How do we support the product?

I often hear about perceived gaps in this model like ‘Where does Finance, Design and Legal fit in?’  To that I ask: Who needs them?  Just kidding.  The true answer is that these pieces get embedded into the core four.  For example, Design could very well fit into the “Build” pillar.  Legal work could very easily fit into the “Sales” component.  Every action item has its place in this model.

If you’re willing to accept the four verbs (build, market, sell, support) as the pillars of product success, then the next step is asking questions.  The goal is to figure out how a successful product launch could be supported by each functional group.  Below are some examples.

Build.  Where are we in the development process?  Is there a beta pilot?  Do we have a demo environment?  Have we defined and validated the initial version of the product?  When is our launch date?

Market.  Do we have an outbound campaign set up (email, press release, call out)?  Do we have an inbound strategy in place (SEO, web assets)?  Do we have revenue goals set up?  Have we communicated with key customers?

Sell.  Are selling teams prepared to sell this product?  Do they have collateral necessary to be successful?  Is there a sales pipeline in place?

Support.  What is the support model for the process to support customers?  Is there a services offering we should consider?  Has the team been adequately trained to support customers?

Posing these questions early on opens up possibilities.  Step two is to narrow down the questions to action items that are relevant for the release.  What’s important to keep in mind is not every tactic should be included in the initial launch.  The laws of economics will eventually determine what scenes make the theatrical release versus what ends up in deleted scenes, or perhaps, a sequel.

The next step is assigning a point person for each to represent each function.  They may not own the work, but they’re responsible for defining what can done for launch and if it’s getting done.  If you have four owners, then you’ve essentially created a scrum team that adheres to the “two pizza team” (three pizzas with mozzarella sticks if I’m one of the four, by the way.)

It’s extremely critical that the four folks representing each area talk to each other … a lot.  Sorting out key dates, deliverables and dependencies is an art, a science, a pain in the ass and a requirement.  It’s also about business strategy though, and finding areas where one team can help another.  Here are just a few examples:

• Can Support help identify upsell opportunities for Sales?

• Can Product pass critical data to Marketing?

• Can Sales provide ongoing feedback to Product?

One of the added benefits of employing this approach is that the model can live on as the team prepares for future launches.  The recurring meetings may not recur as frequently, but measuring success around the launch and calibrating product success in each area will have a pre-set owner who understands the customer experience and product goals.

Let’s get back to our soccer analogy.  If nothing else, employing this model ensures that the players are spaced out across the field, passing the ball to each other and reliant on others to win the game.  At best, you’ll have players acting as a team and not as individuals chasing the ball around.  At worst, everyone will get a participation trophy.