In order to continuously deliver software that is shaped by user feedback, it is better to think of the resulting solution as a long-living product than a time- and budget-bounded project.
One of the most common API-related memes is, “manage your API as a product.” There is no shortage of guidance on this topic. In a previous blog, Mehdi Medjaoui – co-author of “Continuous API Management” and founder of the global API Days event series – gave a well-rounded definition of what it means to apply product thinking to the design, creation, and management of your APIs.
There is another product-related meme out there that is equally popular, with a similarly nuanced definition: “products, not projects.” This notion arose from the principles of the Agile and Lean software movements, and was reinforced when James Lewis and Martin Fowler identified as a key trait of the architectural approach they labeled “microservices.” The idea is that, in order to continuously deliver software that is shaped by user feedback, it is better to think of the resulting solution as a long-living product than a time- and budget-bounded project.
So what does this have to do with APIs?
API products are digital products, and digital products are different than physical products in some significant ways. Most notably, whereas physical products are difficult to change once they have been distributed to consumers, digital products can change right in their users’ hands. And because this trait is known to users, they will often suggest changes to the product provider and form expectations about those suggestions. This feedback loop can be a virtuous circle that improves the product and in turn customer satisfaction, but it also means that change itself is an expected feature of the product. As Mark Maier and Eberhardt Rechtin put it in their landmark book, “The Art of Systems Architecting,” “As technology changes and experience is gained, what is demanded from systems will change as well.”
The changeable core of these digital products is software. Based on the user feedback dynamic discussed above, it makes sense that software will change a great deal once it has been released to users. Software experts have anecdotally used the Pareto principle to express this: for a given software solution, 80% of the work is done after implementation, meaning only 20% is done as part of the initial work. Project-based organizations – formed based on the experiences of physical product delivery – reverse this ratio. They typically put a greater emphasis on initial implementation work than post-implementation maintenance, coming in the form of more budget, higher staff expertise, and greater acclaim. Teams working on implementations are often separate from teams doing maintenance. Clearly, this is not a fit for rapidly evolving software products.
Aligning teams with API products
As the Agile movement rose to challenge the waterfall legacy of IT organizations, Amazon became an early, high-scale adopter of its practices. Instead of splitting up project and maintenance teams, Amazon adopted the credo, “You build it, you run it.” That implied that the same teams who developed a product or service would also be the team operating it. By association, this also made that team the recipient of user feedback, and the ultimate owner and implementer of future changes. The continuity offered by this approach helped team members develop a high degree of domain expertise in their respective business areas. Agile expert Allan Kelly claims that, “In a software development organization, the means of production is the team.” Amazon’s team-centric approach to software delivery helped them improve their velocity, availability, and scalability, a combination of benefits previously thought to be in contention for software systems.
In order to make it possible for these product-aligned teams to function at high velocity, there needed to be a minimal amount of time spent coordinating with other teams. That brings us back to APIs. Amazon was only able to succeed with their new approach because of Jeff Bezos’ legendary mandate stating that all services at Amazon must be accessed only through self-service APIs. By having clear lines of demarcation between Amazon’s software products, the teams building and supporting them could function with a minimum amount of friction. It was not enough for Amazon to just take a product mentality versus a project one; they needed to combine the product approach with domain-aligned teams and API connectivity. Since Amazon paved the way, many other organizations have embraced this paradigm of digital product development – featuring APIs, Agile methods, DevOps culture, and cloud-native technologies – with great results.
So the next time you encounter the “manage your API as a product” meme, keep in mind that one aspect of this statement is that your organization should adopt product-aligned teams that manage their full lifecycle. And when you come across the “products, not projects” meme, remember that API-bounded products give you a better chance of getting the delivery speed benefits you are looking for when moving to a product-centered methodology.
You can explore this “API products, not API projects” approach in greater detail through the “Way of the API” workshop, one of MuleSoft’s API program workshops. Learn more about these new offerings here!
