How Armory Builds Products

Armory is commercializing Spinnaker, a cloud-native continuous delivery orchestration platform created and open-sourced by Netflix and Google to codify and standardize software delivery pipelines to multicloud targets. With much of the world’s software still deployed to data centers, customers adopting Spinnaker are market leaders. They are critical in defining the features that will be broadly applicable as the rest of the market moves towards cloud (and Spinnaker!) migration.

These customers need a set of lightweight minimum viable product (MVP) features they can deploy and test, in turn giving Armory feedback and guidance on how best to commercialize Spinnaker. Our approach of rapidly releasing, iterating on, and then improving on features helps us validate (or invalidate) these features. We are learning alongside our customers and improving Armory Spinnaker on a near-daily basis.

As we build Armory Spinnaker, we are discovering the acceleration and unblocking features that make continuous delivery even more powerful for our current customers. Customers that adopt Spinnaker later in the market process will benefit from our early innovations. And, we’ll continue to discover features with our early innovators that will benefit later adopters. We’ll stay ahead of the Spinnaker flywheel with this iterative approach to building and releasing products and features.

As we learn what the market leaders need – and as our early users and adopters implement it – our engineers return to the proven product and feature set and refactor them for optimal commercial engineering practices. We refactor the code for scalability, readability for internal maintenance, diagnostic capture, documentation, quality and readability.

First, we build the right thing quickly, and then we go back and build the right thing robustly.

The ‘Perfectionist’ Bug

Building the ‘right thing’ iteratively is ultimately more fulfilling than building a perfect thing without feedback. You know you’re building something that users will ultimately use extensively, and that solves true customer needs.

While this may make sense logically, there’s a natural tendency for engineers to trend towards an inherent perfectionism. As engineers, we want to build a perfect product with perfect code. At Armory, we like to remind our engineers of a reality: you will (and can) never build the ‘perfect thing.’ It will always get better based on feedback from users and based on improvements in the tools and techniques in the market.

If you spend an extra ‘x’ period of time trying to build a perfect product for your users, you could have spent that same ‘x’ period of time getting valuable user feedback to iterate on that product. Using that feedback and making the product more useful to your end user enables you to leapfrog what you would have otherwise labored over in a black box of development. Making the product more useful also means it’s more likely to be used widely by those customers.

Armory believes it’s important to start talking about this inherent tendency towards perfection and moving towards coding and building products based on a constant feedback loop from actual users. This doesn’t mean we encourage sloppy coding or development practices. It means we focus on taking the first step and getting something into our customer’s hands. We encourage our engineers to get comfortable building (and releasing) MVP’s, and coming back later to improve on it if it turns out to be headed in the right direction. We consider everything in this process as a stepping stone to something that fulfills a customer need, one that is ‘right enough’ until we get the next round of feedback and make the next set of tweaks.

Armory’s Process: A Feature Example

One of Armory Spinnaker’s most powerful features is pipelines as code. As we built out the features and released the MVP, we were surprised to find that some of our assumptions about why and how customers would use pipelines as code were wrong. Customer feedback drove iteration and also a deeper understanding of the use cases and context for this feature.

Our intention in building pipelines as code was from the perspective of supporting a golden path for infrastructure. We knew that customers wanted (and needed) example pipelines that could be copied and used as building blocks across the organization.

We were surprised and delighted to find that customers immediately began leveraging the pipelines as code feature as a conduit to other use cases. They began using pipelines as code in very modular ways. For example, customers began using the feature to determine who controlled or owned code modules and as building blocks within Spinnaker.

We were also excited when customers began using pipeline as code modules for managed, declarative delivery. This led us to add managed delivery to our product roadmap and work with customers on use cases in this area. We thought we were solving a specific infrastructure challenge. Customer feedback led us to a wide variety of additional use cases that has broadened the value of this feature set. Imagine if we had narrowly built the pipelines as code feature with no customer input – we would have missed valuable customer guidance and context for many additional uses and areas of applicability!

Build the Right Thing Fast

Our approach to building products mirrors our approach to many things – our company culture, how we respond to market trends, and our contributions to the Spinnaker community. We believe that listening closely to customers, our Armory tribe, and the broader Spinnaker community enables us to contribute the highest value and supports the growth of Spinnaker.

Intrigued by our approach to building products? We’re hiring!