Agile Marketing: A CTO Perspective

Joe Kinsella
CTO and Founder
Nov. 17, 2014
5 minute read

The content in this blog is outdated and we cannot reliably say it is still accurate with the speed in which the cloud industry moves. But don’t worry—below are more recent, up-to-date blogs.


Intuit Takes Cloud Cost Optimization To New Heights With CloudHealth

Gartner Report On Managing Cloud Costs

Breaking Down Forrester’s Cloud Cost Monitoring And Optimization Wave


Big companies have every advantage over small companies except one: speed. For all the disadvantages in budgets, resources, market presence and customer base, a small company can deliver almost anything faster than their bigger cousins. In the time it would take me to get legal approval for the open source software my team planned to use in a big company release, I could build, test and ship 4-5 product releases in my current startup.

So it should not be a surprise that one of the founding tenets of my current company was a need for speed. While I put lots of thought into how I wanted to drive our product development process, I hadn’t spent enough time thinking through the implications on the rest of the organization. The result was a chaotic first few months as we learned to build, market, sell and support product releases with agility.

Here are some tips we learned in the process:

#10: Get Buy In

When we first started the company, we were releasing new features multiple times a week, sometimes multiple times a day. Our release cadence was ad-hoc and entirely engineering driven. Our head of marketing was convinced our customers would prefer us to move to monthly releases. At that point it was clear: I didn’t have buy in. If you are going to drive a high velocity release process, you need buy in from all your stakeholders (e.g. customers, marketing, sales, support). I managed to get buy in over time only as our rapid pace of delivery proved to be valued by our customers. But I definitely could have expedited the buy-in process by sharing the impetus and justification behind my pressing need for speed.


#9: Ensure Marketing In Sprint Planning

In most organizations, sprint planning is a meeting attended by the product teams, with marketing steering its influence through a product management team. I’ve always been a firm believer in the Intel wisdom that the next great insight / innovation can come from anywhere in the organization, not just engineering and product management. To achieve this, we designed a sprint planning process that has two parts: the “business phase” and the “technical phase” (a.k.a. the sausage making). The business phase is attended by all functions in the company, and focuses on reviewing the results of the previous sprint, discussing progress toward the themes / epics for the current season, and on reviewing every customer enhancement since our previous sprint planning. The output of the business phase is guidance for the product team to steer the next sprint. The ability to attend a short and focused “business phase” has allowed marketing and other teams to directly exert their influence and gain critical insight into real-time changes in product plans.


#8: Define Release Types

All releases are not equal. We eventually characterized our releases into three familiar types:

By categorizing our releases, we were able to agree to a common language and approach for how to view the product and marketing needs for each release type.

  • Major release - Major new customer-facing features that have a substantial impact on our current and future customers. These warranted full marketing launch.
  • Minor release - Minor new customer-facing features that customers / prospects would want to know about, but had less broad market / industry appeal.
  • Maintenance release - While our maintenance release may add value for targeted customers as a result of a bug fix or performance improvement, there is no external market value to them.

By categorizing our releases, we were able to agree to a common language and approach for how to view the product and marketing needs for each release type.


#7: Define Consistent Cadence

With great disappointment I learned that even if engineering could deliver a major new release every week (we couldn’t), and marketing could support this cadence (they can’t), our customers and the market could not consume this level of change. Instead we had to identify the cadence that worked for us. The velocity will vary by company, product and product phase, but for us this turned out to be maintenance releases as needed, minor releases weekly, and major releases monthly.


#6: Decouple Releases From Marketing

I’ll tell you a dirty little secret: you don’t have to align the delivery of features with the marketing of them. It’s okay to release important new functionality to your customers and only market it a week or two later. That flexibility is important since it frees both groups to execute to the optimum cadence required for their audience and objectives.


#5: Define a Repeatable Process

It took us a while to arrive at a repeatable process. For example: all major releases should have a press release, press articles, blog post series, web site content, sales material, and customer announcement email; all minor releases should have a blog post, web site content, sales material, customer announcement email; etc.... Our head of marketing drove this standardization and it has been serving us well.


#4: Flexibility

As part of the agile process, we prioritized agility over predictability. The upside is that we deliver the right features to our customers at the right time; the downside is we don’t always know the exact day we will deliver them. It also means that sometimes there is a blog post to write or journalist interview that appears on your calendar with little notice from marketing. But both engineering and marketing are now accepting of the flexibility required on both sides to support a high velocity release process.


#3: It Takes a Village

Executing agile marketing takes more time and resources than executing traditional waterfall releases. It took a while for me to fully appreciate how much more needs to be done when you release weekly versus monthly. The only way to get the work done required for launch is for a cross-functional team to roll up their sleeves and help execute the marketing plan. Sometimes this means I have days (okay, weeks) where I think I’m in marketing - but that is the cost engineering must accept to drive a high velocity release process.


#2: Integrate Marketing Into Product

We integrated our release announcements directly in our product, making it easy for our customers to know when something has changed. We have yet to perfect this one, but our feedback loop is steering us in the right direction.


#1: It’s Okay To Drive to a Marketing Deadline

One of the key things I wanted to eliminate from our software development process was friction. My definition of friction: anything that slows and stands in the way of value-add features reaching customers. At first I thought driving to a marketing date was just another form of friction. But lining up customer testimonials, press interviews, and case studies requires elapsed time that cannot be accelerated with a few shots of espresso and a late night coding binge. Aligning to key launch dates can advantage everyone - most importantly your customers and prospective customers.

Last Thoughts

Confession: I’ve learned more about agile marketing in the last few months than I have in the last several years. Much of this has to do with a cross-functional commitment to driving a build, measure, learn feedback loop across every aspect of our product. We are on a journey that will likely yield new innovations in all aspects of our product - including how we market and sell it.