Tools Shape Products

The better I understood software, the more I realized that the tools developers use quietly determine what teams are capable of building.

Overview

As the company grew, I became increasingly interested in a problem that sat underneath the products we were building: the people building software were constrained by the systems around them. Developer tools were often treated as infrastructure rather than product, but small improvements in the way engineers worked could compound across every project, every team, and every release. Building in that environment changed how I thought about leverage.

Category:

Lessons

Published:

May 16, 2019

Updated:

Publisher:

Philip Cross

Reading

7 min

Series

Company

Updated:

Intoduction

For a long time, I thought the most valuable software was the software closest to the customer.

That seemed intuitive. Customers could see it. They could use it. They could understand what it did. Improvements could be measured directly through engagement, retention, or revenue.

The tools behind the product were different. They were mostly invisible.

A better development environment did not appear on a customer's screen. A faster deployment process did not make for an impressive product demo. Better internal tooling rarely became the headline feature of a company.

But over time I started noticing something that was difficult to ignore. The quality of the tools changed the quality of everything built with them.

An engineer who could move from an idea to a working implementation in an hour instead of a day had more opportunities to experiment. A team that could safely deploy small changes could learn faster. A developer who spent less time fighting infrastructure could spend more time thinking about the product itself.

The leverage was not obvious because it was distributed. It appeared everywhere.

The Work Behind the Work

Software companies spend a surprising amount of time building things that users never see. Internal systems. Deployment pipelines. Testing infrastructure. Monitoring. Documentation. Development environments. Scripts that automate repetitive work. Tools that make other tools easier to use.

None of these usually become the product. But they determine how efficiently the product can be produced.

I became increasingly interested in that layer.

The more engineers I worked with, the more I saw how often highly capable people were spending time on problems that had very little to do with the product they were trying to build. A developer might spend an afternoon configuring something that should have taken minutes. A team might postpone an experiment because deploying it was too risky. An engineer might avoid improving an important part of the system because the surrounding tooling made the change unnecessarily difficult.

Each individual problem looked small. Collectively, they were expensive.

The interesting part was that these costs rarely appeared in a financial model. Nobody sends an invoice for the five minutes an engineer wastes every morning. But multiply five minutes across a team, across a year, across every engineer in an organization, and the number becomes significant.

The real cost was not just time. It was the work that never happened because the friction made it feel unreasonable to begin.

Developers Don't Need More Features

This changed how I thought about developer products.

It is tempting to build tools by accumulating capabilities. More integrations. More configuration. More controls. More dashboards. More options. Developers are technically sophisticated users, so there is a tendency to assume they want more power.

Often they want less work.

That distinction became one of the most important principles for me.

The best developer tools do not necessarily expose more complexity. They absorb it. They take something that previously required knowledge of several systems and make it feel like one operation. They turn a fragile process into a predictable one. They make the correct path easier to follow without preventing an experienced developer from going deeper when necessary.

That is a difficult balance. Too much abstraction can become frustrating because the developer loses control. Too little abstraction simply moves the complexity onto the user.

The product has to decide which complexity belongs inside the system and which complexity genuinely belongs with the person using it.

That is not unique to developer tools. It is a general product principle. But developers make the trade-off particularly visible because they are capable of working around almost anything. That can fool you into thinking a workflow is acceptable simply because a talented engineer can tolerate it.

The better question is how much unnecessary thinking the system requires from someone who should be thinking about something else.

Leverage Is Often Invisible

The deeper lesson was about leverage.

A customer-facing feature usually has a direct relationship with its audience. A developer tool can have a multiplicative effect.

If you improve the workflow of one engineer, the benefit may appear in every product that engineer touches. If you improve the deployment process for one team, every release from that team can become easier. If you make a common engineering task ten times simpler, the improvement compounds every time the task occurs.

This made me reconsider what scale actually means. Scale is not only serving more customers. Sometimes scale means improving the system through which other people create value. That is a different kind of leverage.

It is also why infrastructure businesses can be difficult to appreciate from the outside. The product can look small while its effect is enormous. A tool used by a relatively small number of people can influence millions of end users indirectly.

That relationship between invisible infrastructure and visible outcomes fascinated me. It also changed the way I looked at the companies we were building.

I started paying more attention to the systems beneath the interface. Where was work being repeated? Where were people compensating for the limitations of the tools? Which problems existed only because the underlying system had been designed a certain way? And perhaps most importantly, which parts of the process could become dramatically easier if we designed them properly once instead of asking thousands of people to solve them individually?

Those questions led to better products than simply asking what feature we should build next.

The Best Tool Disappears

There is an irony in building developer tools. Success can make the product less visible.

When a tool works exactly as it should, nobody thinks about it. The deployment succeeds. The test runs. The environment starts. The dependency resolves. The developer continues working.

There is no moment where someone says, "What an excellent piece of infrastructure." That is usually the point.

The best tools reduce the amount of attention required to use them.

This changed my definition of sophistication. I used to associate sophisticated software with the amount it could do. Increasingly, I associated sophistication with how much complexity it could hide without becoming opaque.

That is a harder problem. Anyone can add another control. It is much harder to remove ten controls without removing the capability they represented. Anyone can expose the underlying system. It is harder to design an interface that gives people confidence while preserving the power they need when things go wrong. Anyone can automate the happy path. The real product is often what happens when something unexpected occurs.

These details rarely make a launch announcement. They determine whether experienced users trust the system.

That is where I started seeing developer tools less as utilities and more as products in their own right. The customer was simply someone whose definition of a good product included things most consumers never had to think about.

Conclusion

Building around developers changed the way I think about software far beyond developer tooling. It taught me that the most valuable part of a system is not always the part that people see. Sometimes it is the layer that makes everything else possible.

A better tool does not just make one task faster. It can change which tasks a team considers worth attempting. It can make experimentation cheaper. It can reduce the cost of complexity. It can give people enough confidence to build something they would otherwise have left alone.

That is real leverage.

The lesson has stayed with me because it applies well beyond engineering. Whenever I look at a process now, I try to find the friction beneath the visible outcome. What are capable people doing that the system should be doing for them? What complexity has simply been accepted because everyone has become accustomed to it? What would become possible if the underlying tool were redesigned rather than the user being asked to work around it?

Those questions are often more valuable than asking what should be added next.

The best tools do not make people feel like they are using better tools. They make people feel like they are suddenly capable of doing things that used to be too difficult to attempt.

Continue reading

Clarity Is the Strategy

Trust Is a Product Feature

Tools Shape Products

Tools Shape Products

Overview

Intoduction

Intoduction

The Work Behind the Work

Developers Don't Need More Features

Leverage Is Often Invisible

The Best Tool Disappears

Conclusion

Continue reading

Contact

Contact

Contact