How Armory Uses Makelog to Drive New Feature Adoption from Day One
Jun 23, 2022 by Stephen Atwell
For teams that practice CI/CD and ship multiple times a day, waiting weeks to communicate these updates to customers defeats the purpose. After all, if a feature ships and nobody knows about it, did it really ship? You miss out on delivering value to customers sooner, learning which features they’re most excited about, and getting immediate feedback to improve the product.
The reality is most people batch updates because it’s too hard to stay on top of everything as it ships. In this blog post, we’ll show you how Armory uses Makelog for continuous communication, allowing them to communicate value to their customers faster and to drive new feature adoption from day one.
About Armory
Armory helps companies continuously deploy at any scale. They use Makelog for their recently announced Armory Continuous Deployments as a Service offering. This offering includes both SaaS components as well as components that require versioned releases. As a practitioner of continuous delivery themselves, Armory ships multiple features across both SaaS and versioned components, often in the same day.
Armory practices continuous delivery, not just of code, but of customer-facing value.
The communication challenges of continuous delivery
Stephen Atwell, Principal Product Manager at Armory, says, “For most of my career, software teams have traditionally shipped features on a much slower cadence – at most, once every couple of weeks. It was always reasonable to have a single version number associated with the customers entire product, and have multiple features associated with that version. But now, my current team is shipping features so quickly that this pattern is no longer true.”
For high velocity product teams, shipping multiple times a day can make it difficult internally and externally to stay on top of everything that ships.
When shipping multiple times per day, teams typically have 3 options:
Option 1: All changes go behind a feature flag, and customers get value more slowly
Option 2: You ship changes faster than you communicate them, causing confusion amongst your users
Option 3: A combination of Options 1 and 2.
While Armory does both, in order to deliver customer value faster, most features are released to all customers within a day of the code reaching production. However, at their velocity, releasing that quickly requires that they also communicate that quickly.
The solution
In order to communicate as continuously as they release, Armory uses Makelog to generate just-in-time release notes to give their customers access to features as quickly as possible.
“With the Inbox, Makelog provides a single pane of glass where I can easily see all PR merges across all ship vehicles. When a PR merges, I’m able to see that PR, along with its associated Jira ticket, and any other PRs that are associated with that same Jira ticket. I can easily see any comments and notes left by the developer, and decide what, if anything, should be communicated.”
Using Makelog Autodraft, Armory automatically drafts a new release note using context from a Jira ticket whenever its associated PR is deployed, streamlining the process even further.
“We’ve had several features now where customers started using the feature the same day the PR merged, just off our Makelog Ledger updates.”
Leading with the value, not the version
Using Makelog has helped Armory better connect with their users by communicating value, not versions. Stephen says, “Makelog helped me restructure my release notes. No longer do I lead with what version we are documenting. Now we lead with what change the customer should understand. This helps customers first understand why they should upgrade, and then includes the minimum required version of the customer components in order to leverage this change.”
What Stephen wants every PM to know: “In my first role as a PM, my VP explained that, while engineering provided a list of every change, it was just noise. Our job as PMs is to distill this stream of information down to what our users need to know. If release notes are noisy, they are useless because nobody will read them. If they succinctly communicate only information the user needs, they can be a very powerful tool.”
