No big bangs
When launching a new product or feature, the last thing that you want to do is something risky. The most risky kind of launch is a big bang, where the application or feature:
- Is shipped to production only as the marketing launch goes out.
- Is enabled for all users at once.
- Hasn’t been profiled against real load in production.
In order to avoid those kinds of launches, last week we wrote about techniques that engineers can use in order to make product launches safer. To recap, those techniques were to ensure that the team are:
- Planning for usage that is many times beyond what the current system can handle.
- Making use of feature flags in order to constantly ship the feature into production where they can see how it behaves.
- Doing extensive load testing early enough to be sure of the architectural decisions.
- Taking advantage of beta programs with trusted customers to get real, non-internal feedback on the production code as early as possible.
- Using shadow loading to see the real production footprint, without those users knowing they’re using it.
However, using these techniques requires understanding and cooperation from the marketers that are going to be putting out all of the launch material: the new website, the video, the pre-recorded demos, the blog posts, you name it; there’s a lot of content and planning that goes into a high ticket item launching.
For example, they’ll need to know that you’re going to do a phased rollout beforehand in order to bake that into their messaging. They may also need to be flexible with the exact date of the announcement if progress is tight to the deadline, or if the shadow loading highlights that further optimizations need to be made. If the launch is going to target different geographic cohorts in sequence, then the engineers will need to ensure that the switching on or off of feature flags is coordinated in time with the messaging.
How can engineers and marketers work together better?
Questions for your marketing team
The worst launches happen when the only point of communication is the date at which the software is going to ship. Ideally, your product marketer(s) should be present for the duration of your project, at minimum attending the regular sprint reviews to keep on top of progress, and, even better, with them using those reviews as a chance to show how the launch material is coming together.
At the beginning of a project, there are some useful questions that the engineering team can ask so that they can better understand the particular strategic angle of a launch, and make sure that both engineering and marketing collaborate well from that point onward.
- Who is the marketing launch primarily for? Is it for positioning a product or feature in the marketplace before your competitor does, or is it a riposte against existing competing functionality? Is the marketing message primarily aimed at those that don’t use the software in order to generate leads, or is it to re-engage and excite existing users?
- How critical is it that the functionality is live at the time of the announcement?
- What is the contingency plan if the engineering team are unable to make the deadline for some reason?
- Does the new functionality need to be hidden from existing users until the launch happens?
Let’s go through these in turn.
Who is the marketing launch really for?
There are a whole bunch of reasons for doing a marketing launch.
The obvious reason is that we want to tell the world that our glorious new functionality has arrived. But why? What’s the deeper meaning? After all, existing users will notice that the new functionality has shipped because they’re already using the software: a simple in-app message would suffice for alerting them to its presence.
So, aside from adding new functionality for existing users, is the company trying to strategically position itself with the launch of a new feature (i.e. “we are the leaders in deep learning!”) or is it primarily trying to attract more leads for the sales pipeline? Is it both?
Often there are a number of subtle strategic motivations for the marketing message. Making them transparent to the engineers can inform their priorities, and can help form the contingency plan if the delivery is going to overrun.
For example, is the scope of the project completely fixed, or can features be chopped because the timing of the launch is the most important thing? Can we identify which features we could ship without up front? Conversely, is the date flexible because we want to ensure the highest quality product goes out to our current users?
Always talk about Plan B.
If all goes horribly wrong, what’s the minimum we could ship with? Could we move the date and still deliver the same impact with the marketing message?
Decoupling the announcement from shipping
As mentioned earlier, the engineers will be wanting to ensure that the production system is going to cope with the launch, by using techniques like feature toggling, beta programs and shadow loading. But no matter how brilliant or organized your engineers are, from experience, it’ll always be tight getting everything done to the deadline.
Sometimes everything goes spectacularly wrong. This will mean the project is going to be delayed. This might not be anyone’s fault: there could be a security breach, unexpected illness, or a database corruption elsewhere that needs more hands on deck.
So here’s the question: does the software actually have to be live at the time of the announcement in order for the marketing launch to be judged as a success?
If you think back to memorable announcements on stage by big players such as Apple, Google or Microsoft, how often was the product available right at the moment of the announcement? One purpose of these announcement events is to generate momentum and interest so that the new product sells well. If the launch is being judged by sales pipeline KPIs, shipping a bit later probably won’t matter, as your new leads aren’t using the software yet; they’re waiting for a demo.
The first public announcement of the 1st generation iPhone, complete with the in-depth demo by Steve Jobs, was at Macworld in January 2007. The first iPhone units didn’t ship in the United States until the end of June.
Was the initial iPhone announcement seen as a failure? Definitely not. Instead, they chose to do the right kind of messaging at the right time. The first in-depth unveil does not have to be the date that it is available. It’s when you know roughly when it’s going to be done.
Filling the marketing funnel can be done with a compelling story and pictures and videos. It doesn’t need shipped code.
Pleasing existing users versus attracting new ones
Even if your company is laser-focused on growth, you need to put your existing users first.
If they’re using your software daily as part of their job, holding back a legitimately useful feature for a future ideal date in the marketing calendar is doing them a disservice. Rushing a release for the purpose of a marketing splash has the same effect. They’ll know it’s half-baked, and they will think that new lead are more important than their existing custom. Worse, they’ll think you’re being dishonest by observing the quality void between the glorious marketing story and the buggy live software.
Ideally, existing users should be given new valuable features as soon as they’re good enough, especially if they’re paying money. It says “hey, you’re important to us and we’d like you to try this out.”
Those that don’t already use your software may not be attracted enough to buy until a new feature is iterated on. But remember: the video demo of the feature can be more polished, slick and perfect than it actually is. That video can go out beforehand, then the engineering can catch up.
Measurement
How does the company really measure a successful marketing launch? Is it namely on new leads that are generated and delivered into the sales funnel? Or is it the uptake in the usage of the functionality from existing users? Is it both? Are those two measured with equal weight, or is it skewed towards one or the other? Are they measured by totally different departments that don’t even talk about those metrics to each other?
Being clear with how the marketing campaign is being measured can open the door for engineers to help.
If it’s primarily to attract new users, then engineering can help prepare demos, videos and previews well ahead of the time that all of the functionality goes live. This can allow marketing to progress their campaign without being completely coupled to the stability of the feature or the shipping date.
If instead the feature is predominantly for pleasing existing users, then one could argue that time is better spent on in-app tours and big flashing arrows saying “check this out!” rather than a carefully crafted campaign on Twitter and PR Week. Are your existing users reading those sites, or are they just using your application?
Regardless of either scenario, knowing how it should be measured ahead of time allows the engineering team to improve the capture of usage metrics, such as specific types of interaction with the application or feature. This can include distinguishing whether users are new or returning, and which route they’ve taken to land there.
No alarms and no surprises please
What engineering should be aiming for in their relationship with marketing is transparency, and that works both ways. It means no surprises before the launch. It means the engineers feel confident that the marketing message is an accurate reflection of what they are building. It builds camaraderie and trust between departments, and allows launches to be exciting, not painful.
Here are some things to think about as an engineer:
- Don’t feel pressured to give an exact date if it is currently impossible to do so. Instead, the engineering team could give an estimated month, or even a quarter. That doesn’t prevent marketing from planning their work; they can get on with it just the same. As time progresses and the estimate of a quarter becomes a clearer estimate of a month, then specific dates can be discussed. The worst thing to do is to give a exact date in the distant future that you can’t stick to. That’s where you’re putting both yourselves and the marketers under pressure.
- Think about how you can serve the marketing team. Can you keep a stable build of the software running somewhere so that they can record their videos, run webinars and do demos to customers without your latest incremental pushes to production messing it up?
- Get them into your sprint reviews. Regular attendance to see the progress of your work builds empathy and makes marketers more understanding of how the software is being built. As well as their feedback being extremely valuable, they can identify points where they can unblock one of the activities on their side: i.e. the product may be done enough to start webinars, even if many of the edge case bugs are still being ironed out.
If there is a distance between the engineering team and marketing, then something will inevitably go wrong.
Don’t let that happen.
In summary
Releasing software doesn’t have to be a sprint to a big bang on a specific date far in the future. By considering exactly how and why a feature is being launched, there are many techniques that can be used to ensure that the whole thing goes smoothly.
Consider the purpose of the launch. Is it for strategic positioning, to generate new leads, or to please existing users? Is it in fact all of these things, and how is it being measured? Also consider ways that contingency can be built around the launch by decoupling the day of the messaging with the day that all users gain access.
Work on building a transparent and open relationship with your product marketers. Get them in on day zero, show your progress, and plan the rollout of the feature together. Spend serious time thinking about what to do if it all goes wrong. You will both learn a lot from each other.
Shipping is tough, but it can be made easier. Think about it. Why not do it over a coffee with your product marketer?
