Yesterday afternoon I wrote the same proposal three times. Version one at 12:46, version two at 13:16, version three at 13:26. Forty minutes, three documents, and only the last one was about the thing the client actually needed.
I want to write down what happened in those forty minutes, because the useful part is not that I rewrote it. It is why the first version existed at all.
The first version answered a question nobody asked
I had gone into the morning meeting with a pack already built. That was the right call, and I would do it again. What was not right was that I had also already decided what the answer was.
The first proposal described an app. I had given it a name, invented by me, in the naming style I use for my own products. It had a feature list. It was, in fairness, a perfectly competent document describing a perfectly buildable piece of software.
It was also a solution to a problem I had assembled out of fragments before anyone had described the whole of it to me. I had heard enough in the earlier conversations to recognise a shape I knew how to build, and I had gone and built the proposal for that shape.
The meeting is where that came apart. Not dramatically. Nobody told me I was wrong. They just kept describing their work, and the more they described it, the more obvious it became that the thing I had scoped sat slightly to the side of the thing that was actually costing them.
What changed between version one and version two
Two things, and the smaller one taught me more.
The first was structure. The work was not one build. It was clearly three stages, where each stage was only worth doing if the one before it had landed, and the client could stop after any of them and still have something that worked. Version one had bundled all of that into a single commitment, which is easier to write and much harder to say yes to.
The second was the name. I had named their product after my own house style. Version two took my invented name off it entirely and used theirs.
That sounds cosmetic. It is not. Naming their product after my brand had quietly encoded an assumption: that this was my system, which they would be buying access to. Naming it after them encoded the true one, which is that it is their capability, which I am building. The document reads differently once you make that change, and the change in the document was downstream of a change in what I actually understood the job to be.
Version three, ten minutes later, was small corrections. That one was just work.
The uncomfortable part
I have written before about the value of turning work down when it does not fit, in the day I told a client not to hire me. This is the less flattering neighbour of that story. I did not misjudge whether to take the work. I misjudged what the work was, and I did it in the most ordinary way possible, by being efficient too early.
Preparing a proposal before a meeting feels like diligence. Often it is. But there is a specific version of it that is not, and I did that version: I used preparation time to lock in an answer rather than to sharpen the questions. By the time I was sitting in front of them, the cost of being wrong had gone up, because I now had a document to defend.
I did not defend it, which is the one thing I got right. I threw it out the same afternoon.
This is the same mistake I write about publicly
The thing that stung slightly is that I published a post this morning arguing almost exactly the opposite of what I did yesterday.
It is about which processes to automate first and which to leave alone, and the whole argument is that the ranking comes before the building. Work out what the job actually is, in what order, and what should not be touched at all. Only then decide what to build.
I wrote that, meant it, and had spent the previous afternoon building a solution before I had finished understanding the problem. Not in a client's business. In my own proposal, for a client whose problem I had summarised too early.
I do not think that makes the argument weaker. I think it is why the argument exists. The pull toward starting is strong, and being the person who tells other people to slow down is not the same as being immune to it.
What I am actually changing
Not the preparation. Going in with a pack is still right, and the pack was useful even though the proposal built on it was not.
What changes is what the pack contains. It should carry the questions I still cannot answer, listed explicitly, rather than a finished recommendation. If I cannot say, before the meeting, exactly what it costs them today and how often it happens, then I do not know enough to have scoped anything, and any document I have written is a guess wearing the clothes of a proposal.
Right now that project is waiting on exactly that: their own figures, which I asked for after the meeting rather than before it. Those questions should have gone out well before I opened a document. Asking them first would have taken the whole of yesterday afternoon and turned it into one document instead of three.
The honest summary
Three versions in forty minutes is not a story about being fast. It is a story about how quickly a wrong understanding falls apart once it meets the person who has the right one, and how much of the work I did before that meeting was worth nothing.
The rewriting was not the expensive part. The rewriting was cheap, because once I understood the job, the document almost wrote itself. The expensive part was all the time before it, in which I thought I already knew.