Speak the problem

You already produce the richest input you will ever give a model. You produce it every day, in meetings, in calls, in the ten minutes after a workshop when someone finally says what they actually think.

And you throw almost all of it away.

Writing is compression

When you write something down, you make a hundred small decisions before anyone else sees a word. What matters. What to leave out. How to phrase it so it sounds considered. That editing is invisible and it is not free.

Speech does not do that. When you talk through a problem you include the doubt, the dead end you went down first, the objection you raised and then answered yourself. You use the exact words the client used rather than the tidy version. You leave sentences unfinished because you changed your mind halfway.

All of that is signal. And almost all of it is removed on the way to the page.

The practical consequence: two minutes of talking usually gives a model more to work with than ten minutes of writing. Not because speaking is faster. Because writing arrives pre-filtered.

What the filter removes

It is worth being specific about what disappears, because the losses are not random.

Uncertainty. Written notes state conclusions. Spoken thinking contains "I am not sure about this part", which is the most useful sentence in any specification.

Objections. In conversation people raise things they do not put in writing. The concern someone voices and then drops is often the concern that kills the project six months later.

The exact words. People describe their own problem in their own vocabulary. That vocabulary is the difference between output that sounds like your organisation and output that sounds like a template.

The order things came in. What someone raised first tells you what they actually care about. A tidied summary re-sorts everything into logical order and loses that.

Notes written afterwards are a different thing

There is a distinction worth holding on to: the record you create during is not the same as the record you create after.

Notes written an hour later document what you chose to remember. You captured what struck you, filtered through your own role in the conversation, in the order it came back to you. That is not dishonesty. It is how memory works.

But it means a recollection and a verbatim record are different kinds of material. One can be checked. The other cannot.

Most organisations run entirely on the second kind and call it documentation.

The habit is the whole difficulty

Here is the uncomfortable part, and it is worth saying plainly because it changes what you should do about it.

The technology has been sufficient for years. Transcription sits inside Teams. It comes with the licence you already pay for. Swedish works. Nobody needs convincing that it is possible.

And people still do not do it.

The obstacle is not capability, it is behaviour: remembering to press record when the conversation is already happening and your attention is on the conversation. That is a habit problem, and habit problems are not solved by buying a better tool. Anyone who has written about this for years and still walked out of a café having recorded nothing knows exactly how that failure feels.

Which is good news, in a way. It means the thing standing between you and a significantly richer input layer costs nothing and requires no procurement.

Start with one thing

Do not try to capture everything this week. Pick one recurring situation where you currently type and speak it instead.

Good candidates:

The problem you are about to describe in a long message. Talk it through for two minutes instead. Describe what is wrong, what you have tried, what you suspect. Then work from the transcript.

The brief. Rather than filling in a form about what you want, explain it out loud as if to a colleague, including the parts you are unsure about.

The debrief. Straight after a meeting, before you write anything, say what happened and what you think it means. Two minutes, unedited.

You will notice immediately that you say things you would not have written. That is the whole point, and it is the reason the rest of this series has something to work with.

What comes next

Recording one thing is the habit. Capturing everything that is said is an infrastructure question, and it has an answer that is less obvious than it looks -- because not all of what you capture may be treated the same way.

That is Part 2.