Wouldn’t it be awkward if you spent a lot of time and money marketing a new product and then didn’t have anything to deliver on launch day?
If you’ve been involved in any product launches, you probably know this:
Things go wrong — from unexpected changes in scope, engineering delays, fatal miscommunications and untimely rollouts.
That’s why at ProdPad, we don’t bother with marketing until after a product launch. We quietly test and launch our new features and releases first, then start marketing when it’s live and working.
We’ve effectively decoupled feature marketing from the deployment date – and it works like a charm.
Where did this approach come from? Well, it’s linked to the way we approach product management. ProdPad itself is a product management tool that we designed for product managers to communicate their priorities, but stay flexible around when and how to solve a problem.
This empowers product managers to quickly shift priorities around the product roadmap when issues arise, and even to redefine the scope of their projects.
So here’s what that means for product marketers whose work depends on decisions made by their product managers.
Do Not Promise Features Or Launch Dates
This one deserves two exclamation marks, because it’s so not worth making a public commitment to something that you’re not 100% sure about.
Once you set expectations, customers expect you to meet them, even if this is what’s really happening behind-the scenes.
- It takes so long to develop that it’s no longer relevant
- You redefine the problem
- The market suddenly changes
So don’t talk about that new feature that’s in development. Don’t tell users that their lives are going to change on April 12th (or whatever). Don’t give them anything to expect, because you will eventually infuriate them if you end up taking it away.
What we do instead is tell customers what themes we’re prioritizing (usually directing them to our public roadmap). Our customers know what problems we’re solving, and we’ll welcome their input but we keep the details quiet for now.
1. Build up an beta/interest group among fans, power users and supporters.
I read the Quartz Daily everyday, so I’m a perfect candidate for this email announcement from Quartz’s Head of Product.
This message is targeted towards regular readers who are probably willing to help test and promote the new product in exchange for early access. The message is light on details, as it should be at this stage.
By building up an interest group now, Quartz gets to test ideas, messaging and product with a crowd that is going to be a lot more forgiving of screw ups than the general public.
Quartz can also mobilize them to help also help give the new launch a publicity boost when they’re finally ready to roll out to everyone.
During beta testing, your product manager will be preoccupied with making sure the solution works as it should, how users are interacting with it, and so on.
Meanwhile, this is a great time for you to try out different ways to package your upcoming changes.
TL;DR: Beta test messaging with your supporters first.
2. Make sure what you’re launching has impact.
I was recently talking to a product marketer with a familiar war story.
He wasn’t invited to early discussions around a feature until it was in production and nearly done. That’s when they called him in, because they figured that’s when he comes into the picture.
“Guys, there’s NO way I can make this sound useful to our users,” he said. “Also, why didn’t you talk to me about this earlier?”
This team had come together and cobbled together a product update that made sense to the small group of people involved. But it was not only difficult to explain, it would also be too low impact to convince anyone to adopt it.
And that put an unceremonious end to a three-month project.
Amazon purportedly has a process for combating this problem.
They write the press release first – as in, the product marketer gets in there first – and then work backwards. It’s called the Work Backwards process.
If the press release isn’t compelling and no one can find a way to make it interesting, then they know what they are planning probably isn’t likely to be received well.
Even if they do go forward on a feature, they go back and compare it to the original press release. Does it live up to the hype? If it doesn’t, they curb it.
TL;DR: Introduce a process that makes it impossible to move forward with a product update without being able to articulate its significance to users first.
3. Have a plan if you’re messing with any core features or workflows.
Remember that day in 2015 when Gchat switched everyone over from the classic UI we all knew and loved to the Hangouts platform that everyone hated?
The reaction was swift and FURIOUS, inspiring headlines around the web like Thank You Google, For The New Homework Assignment (ZDNet) and the less forgiving F&*@ You, Gchat (Jezebel).
Above all, it disrupted an established method millions of users depended on to procrastinate at work.
Most (or many) of your customers consider themselves successful using only a fraction of your product offering.
Is what you’re planning to launch going to change the way the majority of users experience your product? Then start gathering feedback now.
If you’re taking something away, talk to key user types and practice explaining it, and learn what their qualms are.
If no one seems to care, then you’re one step closer to just launching.
If users do care, they’ll tell you why and you can use their feedback to prep.
Knowing their pain points helps you craft the right message and sell them on the ‘new way’ you’re introducing. It also helps you recommend workarounds.
TL;DR: Learn customer concerns and pain points in their own words so you can prep accordingly for launch.
This post was originally published February 16, 2016 on Drift’s blog.