Betterment Product Lead on Best Practices For Product Launches (Part 2)

Managing Effective Product Launches – Lessons 2 & 3

A few weeks ago, I introduced you to my background in managing product launches – outlining best practices for what to do and what to avoid in bringing a product to market. Here are the two remaining lessons I learned in the course of launching Pandora Premium in early 2017.

Create products and their purpose.

Here’s a common scenario: you’re working on a product or feature. You spend days, if not weeks and months, on user stories and acceptance criteria. You run dozens of usability tests to figure out how to make it easier to use or how to surprise and delight. You’re finally ready to kick this thing off. You punctuate your PRD with something like, “users navigate to this feature from a link on the home page.”

My friend, you’ve just made a grave mistake.

How users encounter your product matters a lot. You can build what user tests tell you is the best product in the world. If your actual users don’t see any reason for it, does it really matter? 

This isn’t about ensuring discoverability, it’s about creating purpose. The distinction is subtle but important. With discoverability, the question you’re typically trying to answer is, “how will users find this thing that I’ve built?” With creating purpose, the question becomes, “how do I design both the product and the need for it?”

It’s a much harder problem to solve, but it’s worth the time and effort. Our target audience for Pandora Premium was a subset of our existing listener base: those who loved us and weren’t also using Spotify or Apple Music. Generally, these listeners were happy with our product—listening hours and monthly retention rates were high. So, we suspected that simply telling them about Pandora Premium wouldn’t be enough; we had to get them to feel the need for it. 

We started simple.

First, we triggered interstitials touting specific Premium features at moments in our product when listeners were approaching (or hitting) the constraints of radio. Hate this ad? Never get an ad again when you subscribe to Pandora Premium. Love the song you just heard? Play it again…and again…and again on Pandora Premium.

After our success with these interstitials, we started wondering what would happen if, instead of bringing listeners to Premium, we brought bring bits and pieces of Premium to our listeners. Would giving them an amuse bouche whet their appetite for the full meal? When listeners searched for songs—a very common behavior—we tried giving them the option of playing the song (Premium feature), in addition to creating a station inspired by the song (non-Premium feature). If they chose the former, we presented an upgrade at the end of the experience that connected that “micro-Premium” moment to all Premium had to offer: if you liked hearing that song, you’ll love Premium.

Manage your dependencies—ruthlessly.

It’s a simple rule: don’t build more than you need. We often focus our trade-off decisions on the core product experience. How many edge cases do we deprioritize before things start to feel broken to more and more users? Could we live without that fancy animation for a few weeks? 

The same questions need to be applied to a project’s dependencies. The tricky thing about dependencies, though, is that they’re often owned by somebody else, like customer support, engineering, or content. So you either assume that somebody else is asking the questions to manage scope or, worst case, you kinda forget those dependencies exist and end up in an 11th hour slash-and-burn scenario with your stakeholders, creating an on-the-fly definition of “good enough” that’s hopefully good enough itself so you can carry on with getting your product launched.

Treat your dependencies as you would your core product.

Remember, your product is a package deal: everything that launches with it is along for the ride as you learn what works and what doesn’t. The bigger the package, the slower the iteration toward perfection. So, ask yourself, and your stakeholder partners, if they really need all of those customer support features or performance dashboards or whatnot on day 1. If part (or—god forbid—all) of the product fails shortly after launch, how many of those dependencies will go down with it before they ever get used?

Bringing a new product or feature to market is a labor of love, regardless of its size. As product managers, we hear a lot about minimum viable products and lean solutions, but we don’t talk enough about creating the right conditions for those products and solutions to succeed, particularly when what you’re launching is an augmentation of an existing product. Take the time to do so—your users will thank you.

Click here for Part 1

Click here for our latest blog posts