How Armory Builds Products

Jan 16, 2020 by Andrew Backes

There are two primary approaches to developing and delivering software products. The first is to spend a long time building a product for end users before releasing it and seeking feedback, and optimizing for traditional engineering standards like reliability, scalability, and quality along the way.The second approach is the one Armory embraces: getting a product into our customer’s hands as quickly as possible so we can rapidly get feedback and iterate based on that feedback. As a startup, we have to optimize for speed. We are nimble, responsive and conscious of our resources. Our philosophy is to optimize for speed: ‘build the right thing fast, instead of the wrong thing, right.’ Our rapid feedback and iteration loops enable us to quickly assess and determine whether we are developing the right product with the right features, for the right customers. Once we have confirmed that a product or feature satisfies a market need, we improve on it by optimizing for those traditional engineering standards.The Iterative Process and Spinnaker

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!

Share this post:

Recently Published Posts

Lambda Deployment is now supported by Armory CD-as-a-Service

Nov 28, 2023

Armory simplifies serverless deployment: Armory Continuous Deployment-as-a-Service extends its robust deployment capabilities to AWS Lambda.

Read more

New Feature: Trigger Nodes and Source Context

Sep 29, 2023

The Power of Graphs for Ingesting and Acting on Complex Orchestration Logic We’ve been having deep conversations with customers and peer thought leaders about the challenges presented by executing multi-environment continuous deployment, and have developed an appreciation for the power of using visual tools such as directed acyclic graphs (DAG) to understand and share the […]

Read more

Continuous Deployments meet Continuous Communication

Sep 7, 2023

Automation and the SDLC Automating the software development life cycle has been one of the highest priorities for teams since development became a profession. We know that automation can cut down on burnout and increase efficiency, giving back time to ourselves and our teams to dig in and bust out innovative ideas. If it’s not […]

Read more