2026-06-11: Do Not Listen to the Users

Most people never listen. - Ernest Hemingway

Doing exactly what your users tell you to do will end in failure. You users do not understand system design. They do not understand software development. Often they do not understand the full picture of the business they are operating in. Doing what your users say will lead to churn, which is expensive and wasteful.

Of course, what your users are saying is very, very important to understand. They are using your product (oftentimes, you are not using your own product nearly as extensively). Their problems are real. But in an effort to be helpful, users often come with a solutions. And these we should be extremely wary of.

One of my favorite personal anecdotes in this space relates to a data ingestion system. The system worked very well for the users. The users simply had to ask the development team for whatever they wanted, and the development team had to implement it. There was no user interface. All of the logic was built in to the backend. It lacked flexibility. It lacked configurability. But it had a property that users loved: they did not have to do anything.

The users complained frequently about the time it took to implement changes. Any changes had to enter the development pipeline and go through the usual series of ceremonies before making it to production, which often meant lead times of over two weeks. For major changes, this was not an issue. For minor changes, this actually presented a major problem to the business, the users, and the developers.

The users suggested many process changes in order to accommodate this workflow, including a special team to do direct to production work! Not only would this be expensive, it was also dangerous to the stability of the entire platform, and violates numerous principles about good software development.

The solution that was ultimately implemented received significant pushback from the users and their managers. A system was built to allow the users to do all of the configuration on their own. This was very problematic for the users, because now they were responsible, and they had to do the work.

The business ultimately received a tremendous benefit from this effort: developers had more time to add new features, client requests were implemented more quickly, changes were completed more quickly, users could iterate on configuration and vendor feedback very quickly, and scalability was delivered. Scale in the system (in terms of supported integrations and configurations) was no longer dependent on developer labor. Analysts could quickly configure (or copy, or import) integrations. Even the analysts had more time: instead of trying to explain what they knew to product managers and developers, they were empowered to do it themselves. Fewer hops in communication, time saved, better results.

Because we didn't listen to the users.

Feedback should be welcomed. Feedback also needs to be considered carefully. Most feedback you receive is probably not worth acting on. But it is up to you, as a developer (or product manager) to deeply understand the feedback, understand how it relates to your product, and decide how it fits in with your overall product strategy.

In addition, AI makes listening to the users very easy. The users can even make the changes themselves. But this needs to be resisted very strongly, because the users are not trying to develop a product, they are trying to solve a problem (indeed, the great value in AI is likely in allowing users to build one-off, throwaway tools for themselves to solve problems).

Previous: 2026-06-08: Your CTO Needs to Code

Next: 2026-06-12: The Optimal Number of Unreviewed PRs is Not Zero [Reblog]