“Everything is now moving fast so communication has to be fast as well. But the tragedy is that we have attained this speed at the cost of depth of words.”
– Javed Akhtar, Indian poet
The pace of change has never been faster. This is especially true in software development as code developed in the morning can be tested, integrated and released in minutes to live users. How can marketers keep up?
The connection between Engineering and Marketing can be fuzzy, and at many organizations there may be a relative gap in communication. To engineers, marketers are those smarty pants storytellers who spend their days talking about the product.
To marketers, engineers are those smarty pants’ glued to their keyboards, armed with nerf guns and writing code that will magically manifest into a product.
To each team, the function of the other seems foreign. Host a webinar? Work on messaging? Not for me. Design a backend architecture? Automate regression testing across the platform? No way.
Yet, on the surface, marketing and engineering share a similar responsibility: Deliver value to the customer. To do this effectively, and drive success for the business, each team will be plugged into the other team’s work. This level of coordination is easier said than done. Often the PM will be responsible for bridging the work of the two teams. (I purposely use “PM” generically. “PM” could mean the Product Manager, Project Manager, Program Manager or Product Marketer connecting the functional dots, depending on the size of the organization.)
In the digital age, now in it’s fifth decade, both Marketing and Engineering teams are empowered to move faster. Using automation software, Marketing teams can quickly deliver client communications, push social updates to multiple platforms simultaneously and even leverage AI to write copy on behalf of a human.
For engineers, continuous integration and delivery (commonly known as “CI/CD”) is not a nicety, but a necessity. With the right tools, Engineering teams can test and push code at the speed it’s written and tested. CI/CD has evolved into table stakes tech for agile teams who wish to release updates after every two or three week sprint. In fact, CI/CD has become so effective and reliable, many teams will push code as soon as it’s ready.
In the silo of an individual function, these capabilities are advantages. However, the increasing speed of delivery also poses cross-functional challenges. At a high level, a continuous stream of software updates can create havoc for teams who are asked to support the changes. Here are two challenges teams face in this area.
- Challenge 1: “Lucille Ball and the Conveyor Belt”: “I Love Lucy” is a classic sitcom show that goes back 60 or 70 years. In one episode, there is a classic scene in which Lucy, played by Lucille Ball, takes a gig at a chocolate factory. Lucy is tasked with working the conveyor belt, but the speed becomes too much for her. Hijinks ensue.
Lucy isn’t alone. Often, the rate of change is too fast for certain teams. Yes, it’s great to be receiving constant updates to the product. However, there’s a cost. Customers will want to be prepared for most changes. At some point, does the rate become too much for the customer?
Similarly, Internal teams are left stretched thin keeping up with the conveyor belt of changes. Consider various functions. Is Sales ready to speak to the newest items? Have they worked these additions into their talk track or demo? What about the Support team? Is the business ready to field phone calls on changes taking place? And lastly, can the Marketing team keep up with these incremental changes while maintaining their go-to-market objectives? This topic leads us to the second challenge.
- Challenge 2: “JRR Tolkien and the Tapestry”: If your team is releasing a trickle of updates, there’s a risk of missing an opportunity to tell a more compelling story. How do these changes to the product – when considering in unison – solve a bigger problem? Consider what JRR Tolkien once wrote about storytelling:
“It is indeed easier to unravel a single thread — an incident, a name, a motive — than to trace the history of any picture defined by many threads. For with the picture in the tapestry a new element has come in: the picture is greater than, and not explained by, the sum of the component threads.”
Fortunately, there are tactics that teams employ to overcome these challenges. Below are several key tactics to consider in managing product launches and optimizing outcomes for your brand and for your customer.
- Differentiate a product release from a product launch. Let’s start with semantics because they’re crucial here. The distinction between a “product release” and a “product launch” could be deemed the thesis for this article. A ‘“product release” – in this context – is the technical publication of code to production environments. A “product launch” – for the sake of this article – is the communication of value to the customer.
Who’s involved in each? A product release is done by Engineering; a product launch is a cross-functional exercise typically managed by Marketing. The product release affects the end user of the product; the product launch affects many parties, including the end users but also including prospects, analysts, the buyers of your product (if not the users) and to an extent, internal constituencies.
Lastly, we should talk about timing. A product release is a point in time, typically. A product launch is often stretched out across a longer time frame, with various stages. By definition, a larger product launch is a program in which multiple parties contribute. Of course, if the product release is small enough, the product launch may not require much and could also resemble a point in time as well. For a larger launch, the product could get launched before its released, and then after the product release, part of the launch activity could include measuring the success of the launch for the customer and for the business.
- Understand the relationship between a product release and a product launch. It’s equally important to understand how the two events are related. To start with a simple example, one product release may relate to one launch. Here’s how that might work: On Tuesday, you release a new home page dashboard to a set of customers and launch this value to the client in parallel. On Monday, the user community didn’t have the dashboard. On Tuesday, they did. The launch activity for this release could have included external communication to the end user, including the value proposition, training and frequent updates leading up to the launch.
Now, thinking bigger, a launch might include a series of product releases. For one, you may release a series of product enhancements and then tell a compelling a story around these releases (remember the Tolkien quote?). Conversely, you can think about launching something big before any product releases occur. This is a helpful tactic. It generates excitement and prepares the client for upcoming changes. Plus, doing so buys you some buzz in the market. Essentially you’re revealing your product roadmap to the world.
- Consider big, infrequent launches. One strategy to consider is to focus your launch efforts on fewer, bigger launch events. Apple and Salesforce come to mind as tech orgs who have employed this model successfully. In the case of Apple, their September launch event has become part of the cultural zeitgeist. Salesforce manages three launches each year: Winter, Spring and Summer. Their customers have come to expect this schedule. This way, launches are predictable (in a good way) and the audience for these products can rely on predictable product events.
The other advantage of doing this is providing internal teams ample time to rally around the launch, rather than spreading their efforts (and investment) on more frequent launches throughout the year.
- Categorize your launches. Even if your plan is to go with big, audacious launches every few months, there will still be product updates throughout the year. From our experiences, marketers have the most success tiering launches into three buckets based on the impact to the customer. One model is to define Tier 1 as a major product launch, Tier 2 as a feature (or small set of features) launch and Tier 3 as simple updates, potentially even bug fixes in some cases. Each tier would come with a generic recipe for success, with the largest tier requiring the most effort and investment in activating the market.
- Gate features. You may now be thinking “Hey, we seem to be talking a lot about product launches now. What about releases? We have code to push!” Got it. Remember Lucille Ball and the conveyor belt? Well, we don’t want to necessarily slow down innovation, just control its output. Pushing out code to the product is good practice, but if the release cadence doesn’t quite line up with your launch cadence (and it likely won’t), work with Engineering and Product to “gate” features accordingly. In this context, gating refers to hiding features to users until the business is ready to introduce them. There’s strategy and coordination involved here, but it’s an advantageous tactic. If you’re not ready to bring a certain feature – or even product – to market quite yet, think about hiding it within the product until you are prepared. This can also be valuable if you’d prefer to beta test features with a small set of customers.
So, where do we net out? Continuous innovation is to be applauded and embraced, however don’t allow it to take control of how you communicate value as an organization. Tell the story you want to tell and build a product around that story. Depending on your business and your customer, landing on the right launch and release cadence is a process in itself. However, invest the time to build the machine. Your customers and your teammates will benefit.
