Between the Idea and the Code

A few years ago, my team and I sat down to build something we had first imagined long before that, a trust infrastructure system meant to reveal hidden connections amongst counterparties. We had tried once already, in an earlier version. It didn't hold up to our expectations.

This time, before anyone touched a line of code, we did something that felt almost indulgent in the moment. We stopped and did real technical research, figuring out which systems and architectural approaches the problem actually required, not writing anything yet, just understanding. That version worked. The idea hadn't changed since our first attempt years earlier. What changed was that we finally understood how to build it, and that turned out to be a completely different problem from knowing what to build.

Once I saw it clearly in my own work, I started noticing it happen to other people too. On a payments product I was consulting for at the time, one of the engineers was handed a fully validated idea with a PRD, one everyone agreed customers needed. He still spent weeks stuck, reworking the same integration a few different ways, not because he lacked skill, but because nobody had done the research to map out how the pieces were actually supposed to fit together before handing it to him. Different project, different person, same missing step in the middle.

Most teams treat product development as two steps. Someone decides what to build and writes the beautiful PRD, then an engineer builds it. That leaves out a whole layer, and it's usually the layer that decides whether the first two ever actually connect.

Three things have to happen, not two

Knowing what to build is the first skill. It's taste, empathy, market instinct, the ability to spot a real problem and validate that people actually want it solved. This part gets most of the attention in product culture, and it deserves some of it. But having a clear picture of the destination doesn't mean you have a map to get there.

Knowing how to build it is the second skill, and it's the one that goes missing most often. It's easy to lump it in with two things it isn't. It isn't customer experience, that's ideation's job. And it isn't core architectural design either, architecture is what you draw once you already understand what you're working with. Elucidation comes before that. It's the deep research that has to happen first, figuring out which systems, tools, and unfamiliar mechanics a specific problem actually involves, before anyone is in a position to architect anything. It's the part a quick search or a prompt to an AI model usually can't do for you, because the answer doesn't exist anywhere yet in a clean, searchable form. Somebody has to go dig it out, before the diagram gets drawn, not while drawing it.

Actually building it is the third skill, and it's the one everyone assumes covers the other two. It doesn't. An engineer can hear a validated, well understood idea and still build it wrong, not from lack of skill, but because nobody handed them a clear path from the idea to the code. Standard product work usually covers how a customer will experience a feature. It rarely covers the engineering path for something genuinely new. Ask a builder to discover the how while also writing the what, and you're asking one person to do two different kinds of thinking at the same time. It shows up as slow, wobbly progress that looks like a skill problem but usually isn't.

There's real research behind why that split matters. Cognitive Load Theory, first described by educational psychologist John Sweller, holds that working memory has limited capacity, and that building a mental model of a new problem and executing a known procedure are different kinds of mental work. Ask someone to do both at once on unfamiliar ground, and performance drops, not because the person is less capable, but because the load exceeds what working memory can hold at one time.

Separating the research from the writing isn't generosity with time. It respects how thinking actually works.

Three different muscles, rarely all in one person

That's exactly what I saw happen with that payments engineer once someone finally sat down and mapped the integration properly. He took the same idea he'd been stuck on for weeks, looked at the clarified path once, and built the whole thing in days. The idea never changed. What changed was that the middle step finally got done, by someone, before the code, instead of being left for him to figure out mid flight.

I've also seen the reverse profile just as often. There's the person who's brilliant at the research and the mapping, who can walk into unfamiliar territory and come out with a flawless plan, but who has no interest in or patience for actually writing the code themselves. Both are normal. Neither is a lesser skill set. They're just different muscles.

Most people are strong in one of these, decent in a second, and thin in the third. That's normal. The mistake isn't having people who specialize, it's building a team or a process that assumes one person, or one role, should cover all three by default.

Why this matters more now, not less

AI has made the third skill, writing the code itself, closer to a commodity than it's ever been. Almost anyone can prompt a reasonable first draft of implementation. What AI still can't do reliably is the middle step, the actual research into an unfamiliar, specific problem that hasn't been solved cleanly before, because nobody's written it down anywhere yet in a form a model can retrieve. That gap, and the taste to know what's worth building in the first place, are becoming the two things that actually separate teams that ship something real from teams that ship something that almost works.

If your team is slow, or your builds keep slipping, before you question anyone's talent, look at whether you're asking your builders to also be researchers, or your visionaries to also be architects. Separate the three, and give each one room to actually do its job.