you can't pick the paint before the blueprint

I was recently in a working session where I got a long list of specific questions about a project I'm responsible for. Each one asked me to make a concrete decision. Every question was reasonable to ask on its own, and answering any single one would have taken me a minute at most.

I stopped and said I could not answer them. Not because the questions were bad questions, but because there was nothing underneath them yet. We did not have a real design for the project, the kind of design that says what the finished thing actually is, what it does, and how it runs once it's built. We had pieces: some decisions made along the way, some notes, nothing that added up to an actual picture of what we were building.

That refusal is the whole story. It is worth slowing down on, because giving in to the pressure to just pick something and keep moving is easy, and in my experience, that is exactly how projects end up built on decisions nobody actually made on purpose.

why the questions could not be answered

Every one of those questions assumed a design already existed somewhere, a place I could go look up the answer. There wasn't one. Answering the questions anyway would not have meant answering them. It would have meant inventing the design, one convenient pick at a time, and calling the result a decision instead of what it actually was, which was a guess.

I told the person asking exactly that. I said I did not know how to answer a long list of specific questions about something that had no real design behind it: no answer for what the finished thing actually looks like, how it gets delivered, or how it runs from start to finish. There was no design document to point to. We had a process for building things in the right order, and this was skipping straight past it.

a record of decisions is not a design

Part of what made this harder to see in the moment is that it looked like we had something written down. There were notes. There was a record of decisions that had been made along the way. It would have been easy to treat that record as if it were the design and start answering questions from it.

It is not the same thing. A record of what was decided tells you what got ruled on and when. It does not tell you what the finished product is, what it actually produces, how it reaches the person using it, or what happens when something in it fails. Those are design questions. A log of decisions answers none of them by itself, no matter how thorough the log is.

what a design actually has to answer

In my experience, a real design has to answer four things concretely before anything else matters: what the finished product is, what its output actually contains, how it gets delivered, and how it runs end to end, including what happens when it breaks. Everything past that, the specific technical choices and the order you do them in, comes after those four answers. It does not replace them.

That is why I could not answer the questions I was being asked. Every one of them was a downstream question, dressed up as if it were the starting point. Answering them first would have meant deciding the design by accident, a piece at a time, and finding out later that the pieces did not add up to anything coherent.

the cost of saying not yet

It would have been faster to just answer the questions in the room. Nobody would have stopped me, and I think that is exactly the problem. For me, the pressure to decide is strongest right when I have the least business deciding. A decision, even a bad one, feels like progress. A pause does not.

I said not yet instead. I told the person we had a process for this, and skipping it would not save us anything, it would just move the real work to later, at a worse time, after more had already been built on top of a guess. None of the specific decisions I was being asked to make matter yet. They cannot be answered until there is a real design to answer them from.