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.
Measure, Iterate, and Evangelize
A product doesn’t stand still, and neither should our internal tools. Treating code as a product means committing to its lifecycle. This involves a continuous loop of feedback, measurement, and improvement.
-
Measure What Matters: How do we know if our internal product is 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. It allows us to move beyond assumptions and make informed decisions about where to invest our efforts. We can prioritize the features and improvements that will have the most significant impact on developer productivity and happiness.
-
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.
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.