Shifting our perspective to see code as a product is a powerful first step, but it’s not the end of the story. The real challenge—and where the true value lies—is in continuously adapting that product to the developers who use it. After all, a product that doesn’t evolve with its users is destined to be left behind.
In the first part of this series, we discussed the essential principles of treating internal code as a product. Let’s look at how we can bring those principles to life.
Evangelize, Measure, and Iterate
A product doesn’t stand still, and neither should our internal tools. Treating code as a product means committing to its lifecycle. This mirrors the Build-Measure-Learn feedback cycle from the lean startup methodology.
-
Evangelize and Drive Adoption: A great internal product is only valuable if people use it. We need to become evangelists for our own tools. This means “marketing” them internally—communicating the value proposition, writing clear release notes, and actively encouraging adoption. By celebrating our internal products and their successes, we can build a culture of continuous improvement and shared ownership. Without adoption, there’s no feedback to gather.
-
Measure What Matters: Once developers are using your platform, how do we know if it’s successful? We need to measure its impact. This could be through developer satisfaction surveys, tracking adoption rates of a new library, or even looking at engineering velocity metrics like the DORA metrics. The goal is to gather concrete data to understand what’s working and what’s not.
-
Iterate Based on Feedback: This data creates a powerful feedback loop that allows us to move beyond assumptions. By treating developer support as a core part of this cycle, every interaction becomes an opportunity to learn from our users. This qualitative feedback helps us understand their challenges and prioritize the features and improvements that will have the most significant impact on developer productivity and happiness. Then the cycle repeats: evangelize the improvements, measure their impact, and iterate again.
A New Way of Thinking
Adopting a “Code as Product” mindset isn’t about adding more process or bureaucracy. As engineers, we take pride in our craft. This mindset channels that pride in a new direction. Instead of being protective of our code, we should be proud that others want to use and extend it.
The ultimate measure of our work’s quality becomes the experience of the next developer. Are they happy? Are they productive?
It’s about moving from a reactive, ticket-based approach to a proactive, value-driven one, where the value is measured by the success of our fellow developers. By thinking of our internal code as a product, we can build a more robust, maintainable, and enjoyable development ecosystem for everyone.