“Wait, what’s getting released next week?”

“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.     

Marketing Personas: Five Areas to Focus On … and Five Areas to Ignore

Marketing personas are a pretty sweet deal.  Basically, you or I can read a page or two of content and gain a relatively thorough, base-line understanding of the customer.  Who wouldn’t take this deal? 

It gets better, too.  Multiple functional teams within an organization will benefit from a set of customer personas.  For instance, armed with personas, a marketer will better craft positioning.  A salesperson will more easily discover customer pain points.  R&D teams will have better direction – and empathy – for whom they’re building a product.

However, this is all assuming a persona is done well.  

Like most things in life, personas run the risk of getting drowned in noise, thus losing its appeal and, ultimately, its audience.  Unfortunately, it’s quite common for one to read a persona and ask “How does this actually help me?”  So, how do we avoid this risk?  After speaking with dozens of seasoned product marketers about personas, we summarized some of the key learnings.  

  1. Spend more time on: Role and responsibilities.  Don’t shortchange the basics.  Job title is a great descriptor, don’t be afraid to go a bit deeper on the role.  What was this persona hired to do?  What is their domain at their organization and why is that important?  Are they a subject matter expert?  If so, of what?  

… and less time on: Demographics.  Often, folks want to add fun details to the persona to make it seem “real”.  Examples might include age, political leanings and favorite book or tv show.  We totally get that this might be fun, and in some rare use cases, relevant.  However, these made-up factoids often distract from the real information rooted in real research.  Unless the demographics help tell the story or help your peers better understand customers, we’d recommend you drop the marital status or hobbies of your persona.   

  1. Spend more time on: Challenges and goals.  The value of knowing what a persona is currently striving to achieve and what stands in their way is the information your teammates are desperate for.  Ultimately, your organization exists to help the customer solve the problem and hit their goals.  These insights are a goldmine.

… and less time on: Personality traits.  Wouldn’t it be great if all of your customers shared the same personality?  Not only is adding this unwise, it’s inaccurate; a downright waste of time.  Save the Myers Briggs tests for working relationships with real peers, not fictional characters who – in aggregate – don’t have but one personality.

  1. Spend more time on: Sharing and distribution.  What good is a set of personas if no one can find it?  Having one source of truth for personas across your entire organization enables less confusion, better management of the document and certainty that everyone is speaking the same language.

… and less time on: Graphical design.  I love a great design as much as anyone, and if you can land a slick design that’s appealing to the reader, by all means go for it.  But the snazzy persona document that no one can find won’t win you many points.

  1. Spend more time: Specificity through persona types.  What seems obvious deserves a mention: Differentiate your buyers from your users and perhaps your champions from your detractors.  This distinction will be helpful to all.  By ignoring aforementioned information that isn’t helpful, focus more on persona variations.

… and spend less time on: Alliterative titles.  Eh, who am I kidding?  We love Charlie the Champion and Debbie the Detractor.  Keep these coming!  

  1. Spend more time on: Living documentation.  Your business will change, and your customers will too.  As customer needs change, technology evolves and you grow your business, make it a habit to update personas at a cadence that instills in your cross-functional teammates that personas is an ongoing investment and reflective of the world today.  

… and less time on: Perfection.  As they say, don’t let perfect get in the way of good.  If you don’t have personas at the moment, simply publishing the information you have gathered from research has serious value for your peers who can make good use of it.  

What do you think? What did we miss? Want to manage your personas (and product launches!) with Launch Day? Shoot us an email at john@launchdayapp.com.

Help I Need a Launch Plan! Take our Template

“The hardest thing about getting started, is getting started.” That’s a quote from Guy Kawasaki and I bet it resonates with all of us, especially when embarking on a journey for the first time. Whether it be building a home, baking bread or launching a new product, it helps to have somewhere to start from.

While we can’t provide the blueprints for home construction or portions of yeast, we can help you get off the ground with a product launch. And we’re happy to do so.

Here is our template for a product launch, whether it be a new product or an enhancement to an existing product. Obviously, you should take this template and make it your own. Change the priorities, remove items that aren’t needed and make the timeframe real for your organization.

This template is free to use but we’d kindly ask for your help in making this template even better. What are we missing? How can we make this template even better for the launch community? Share in comments below.

If you have any questions or need any help bringing your launch to life, email us.

Thanks and happy launching,


How to Orient a Launch around a Date

Diana Scharf Hunt, the author of “Tao of Time” once wrote that “goals are dreams with deadlines.” In other words, we as humans have the ability to economize and leverage time as a currency. It can drive us, make us anxious, become a rallying cry for a team with audacious goals.

On the flip side, author Douglas Adams is quotes as saying “I love deadlines. I like the whooshing sound they make as they fly by.” A different perspective, perhaps.

If you’re like me, you respond positively to a stated date. For god’s sake, it’s why we named our product “Launch Day”! So, in terms of launch orchestration, what is the date? Really smart marketers have told us that launches never really end, and we get that. But if the team is to timebox their efforts of getting out to the market, how can a launch team achieve this?

Here’s what we find works. Pick a date as the event. In some cases, maybe it’s the day that the product release gets rolled out to the masses. Maybe it’s the day the press release hits the newswire. Maybe it’s the day you host an internal webinar for your organization. This single day is your Launch Day, your orientation point. In our example, let’s call that “June 15”.

Armed with a date, one can now plot out everything that goes into a product launch. So, next step is defining everything other activity or task necessary to make the launch a success. In these terms, define items as “t-minus” in days. So, how long before the launch do I need to have my pricing in order? Two weeks? Cool, then the deadline for pricing becomes “June 1”.

The “t minus” model works because all activity is built around supporting the most important part of the launch.

Is this a model you use or want to use? Something else? What do you like or dislike about defining a “launch day”?

Happy launching,


On Launching: A Simple GTM Framework

Pretend you’re standing on a train platform, waiting for your ride.  When it arrives, the train is near full and the conductor calls out “all aboard”.  So, you hop on and the train proceeds forward.  Of course, you don’t ask the conductor questions because the schedule of the train is set as are the tracks and the destination. 

Conversely, launching a product or feature release is quite different.  While it may seem like everyone knows the direction and destination, are we sure?  Has anyone written it down?  Have we communicated it enough to ensure clarity?  In a fast-paced environment where everything is due yesterday, we have an opportunity.  We are afforded a “time out”.  We can request information, even if it means slowing down the train, if only for a second.

Launch Day is happy to introduce our Four Stage Launch Framework.  The purpose of this framework is to align your team around a product launch, ensuring future success, efficiency and installing the “North Star” direction the team can align around.  Our process starts by defining organizational goals, continues to sizing up opportunities, developing an execution plan and then gauging success.  Find the framework and a description of steps below.  Happy launching! 

Stage 1: What are our business goals?

What are we trying to achieve for our organization or business unit?  Where can we “move the needle”?  Oftentimes these goals may be defined as OKR’s.  At some (often smaller) companies, it’s less formal and maybe a decree from the leadership level.  Regardless, we recommend formally defining goals and then deciding on key performance indicators (KPI’s) that can be used to measure the goals.  Lastly, capture the KPI measurements as they are today.  These will serve as your baseline metrics.

Stage 2: How can we create customer value to achieve our goals?

With goals in mind, now it’s time to figure out what we can do to achieve said goals.  A new product line?  Pricing changes?  Better onboarding? Rebranding?  A collection of product feature requests?  In this phase, there are two assets to build out. First, list your product/marketing/business opportunities. Then, size up the opportunities against the goals/KPI’s from phase 1. Some companies will use a weighted scorecard for this.

Stage 3: How will we deliver value to clients?

There’s a reason these phases happen in succession.  Having defined, scored and ranked various opportunities your team should now be primed to plan.  Build a roadmap to track opportunities over time periods coupled with the accompanying go-to-market events that will support the roadmap.  The launch plan will be exhaustive, capturing key activity that will be necessary to achieving the goals stated in phase 1. 

Then, it’s time to execute. Press go.  The train’s now moving again and everyone is on board with clear alignment around duration, speed and destination.

Stage 4: How will we gauge success?

How are we executing against our plan?  Here’s where we start tracking the KPI’s again, but now having created a bunch of customer value. Are we seeing the improvement in KPI’s that we expected?  Do we need to tweak our plan?  The success you see at this stage will – at least in part – be attributable to the work done in the first three phases.  Of course, the learnings from this launch will inform the next as the team grows stronger with each successive go to market launch.

Is this similar to your process at your company? Looking to implement something like this? Happy to hear your thoughts!

Upward and onward,

John from Launch Day