pborenstein.dev

We were the product designers all along


For my entire career, I’ve said the main difference between my work and a developer’s work was that I didn’t have a machine I could run my work on.

Developers had a tight feedback loop: write something, run it, see if it works, iterate. The machine told you whether your specification, the program, was precise enough to execute.

Technical writers never had that. We wrote procedures and tutorials, then waited weeks or months to see if they worked when a human tried to follow them. The feedback was slow, indirect, noisy.

Now we have a machine.

When you prompt an LLM, you’re running your prose. Vague input produces vague output. Ambiguous instructions fail. The same skills that made documentation good – precision, sequencing, anticipating confusion, naming things correctly – are exactly what make specifications work.

We have always been doing product design. We’ve just been doing it after the fact and called it documentation. We took the chaotic output of development, half-documented APIs, features that exist for reasons nobody remembers, and reverse-engineered the intent. We figured out what the product should be and wrote it down so people could use it.

That’s specification work. That’s design. We just weren’t allowed to call it that because our work came after the code was written.

What changed is the direction of the arrow. Now, a clear specification can lead to working implementation. And it turns out the people who’ve been doing specification work their whole careers might be better positioned for this than anyone expected.

We have always been the ones who turned chaos into clarity. Now we’re the ones who can turn clarity into code.