I can spend an entire afternoon improving a tool for a conversation I am avoiding. The tool will have good spacing, a thoughtful empty state and absolutely no opinion about why I have not picked up the phone.
Kyle Gawley's October 8 post about building internal tools instead of doing sales made me laugh because it describes a temptation I recognize. I would not use it to diagnose every person building an internal application. Some internal applications are badly needed. But the accusation is worth trying on before dismissing it.
The crucial question is not whether the thing is useful in the abstract. It is which uncertainty building it removes.
Suppose I do not know whether a customer cares about a particular report. I can build a beautiful system that generates the report. I can add filters, exports and a little animation that makes the chart feel pleased with itself. None of that tells me whether the customer's decision improves when the report arrives.
I have reduced an implementation uncertainty while preserving the product uncertainty. It feels like progress because implementation provides immediate feedback. The build succeeds. The interface changes. The box I can control becomes more impressive.
Meanwhile, the question I cannot answer alone waits patiently beside it.
An uncomfortably small experiment
In my imaginary version of this project, I would first write down what the recipient needs to decide. Then I would show them an ordinary example: perhaps a simple table, a sketch or an existing report with the relevant information marked. I would ask what they would do next, what they would distrust and which missing detail would stop them.
That conversation might reveal that the proposed tool is valuable. Excellent. It might reveal that the valuable part is much smaller than I thought. Also excellent, although my enthusiasm for the animation would need somewhere else to live.
It could reveal a different problem entirely. Perhaps the data arrives too late. Perhaps two departments use the same word differently. Perhaps the recipient already has the answer and needs permission to act on it. A more elegant dashboard cannot negotiate those facts into a different shape.
The experiment is uncomfortable because it gives another person influence over the story I have been telling myself. A build error cannot tell me that nobody asked for the thing. A customer can.
This is one reason faster generation can intensify avoidance. When implementing a new idea becomes easier, I gain more opportunities to replace an uncertain conversation with a satisfying construction project. I can produce three versions before admitting that the first question was never technical.
What I would keep
I am not interested in making useful internal work sound embarrassing. A modest tool that removes a repeated nuisance can be a wonderful contribution. The people using it may know exactly what they need. In that case, build it, keep its scope legible and enjoy the time it returns.
What I would stop doing is borrowing that example to justify every new interface I feel like producing. A tool can be technically competent and strategically premature. Those descriptions can coexist without anyone being a fraud.
My test is simple enough to be irritating: before adding the next feature, can I name the person, the decision and the evidence that the change would help? If I cannot, the next task might involve a question rather than another component.
The empty chair across the table is a better product manager than the fifth dashboard in my folder. It keeps reminding me who is missing.
A thought worth keeping?
