Build Before You Know

I stopped trying to predict the right product and started letting real users show me what was worth building.

The image shows a close-up of a sleek, modern jet engine turbine, highlighting the intricate blades and polished metal surfaces, set against a dark background, embodying advanced aerospace engineering.

Overview

Early product development taught me that preparation can become a very convincing form of procrastination. Research, specifications, roadmaps, and strategy all have value, but none can substitute for contact with reality. Once I began treating each release as a way to test an assumption rather than prove that an idea was already correct, the way I built changed completely.

Category:

Education

Published:

Jan 26, 2026

Updated:

Publisher:

Philip Cross

Reading

7 min

Series

Learning

Updated:

Intoduction

There is a particular kind of hesitation that looks like progress.

You are researching competitors. You are comparing approaches. You are refining the product definition. You are discussing edge cases. You are rewriting the roadmap. You are making decisions, revisiting them, and then making slightly different decisions.

You are busy enough that nobody would accuse you of standing still.

I know because I did it.

In the early stages of building, I believed that good product development meant reducing uncertainty before committing resources. I wanted to understand the market, anticipate customer needs, make the architecture sensible, and have a sufficiently clear roadmap that we would not have to keep changing direction.

It sounded disciplined.

The problem was that I was trying to remove uncertainty from a process where uncertainty was the thing I needed to learn from.

There were questions we could answer through research. There were questions we could answer through experience. And there were questions that simply could not be answered until someone had the product in their hands.

I was spending too much time on the first two categories because I was avoiding the third.

That distinction eventually changed how I thought about building.

The Problem With Being Prepared

My original mental model was straightforward. An idea became a specification. The specification became a roadmap. The roadmap became a product. Once the product was sufficiently complete, we would put it in front of customers and learn whether we had been right.

The flaw was obvious in retrospect. The largest assumptions were sitting at the end of the process.

We could decide what we thought people needed. We could study competitors. We could map potential workflows. We could debate positioning and prioritize features. But we could not know how someone would actually behave when the product existed. That required the product.

I had confused making decisions with making progress.

A decision can be useful without being correct. A specification can be detailed without being insightful. A roadmap can be coherent while being built on assumptions that have never been tested. The more time we spent refining our thinking, the more convincing the plan became.

That was precisely the danger.

A detailed plan creates a feeling of certainty that can be stronger than the evidence behind it.

I started paying attention to the difference between activity and information. A competitor analysis gave us information about competitors. A product meeting gave us information about our own thinking. A user interacting with the product gave us information about the market.

Those were not equivalent.

The realization was uncomfortable because it meant some of the work I had considered essential was actually helping me postpone the work that mattered most.

The First Release Was a Question

The turning point was deciding to release something before we felt ready. Not recklessly. Not without thought. But deliberately incomplete.

That distinction mattered.

There is a tendency to interpret "ship early" as "move faster." I think that misses the more important idea. The value of an early release is not that you have produced something quickly. The value is that you have reduced the distance between an assumption and the moment it can be tested.

Once we looked at the product that way, the scope changed. Features that had previously felt essential became things we could postpone. Some of the complexity we had planned was revealed to be complexity we had introduced ourselves. Decisions that felt urgent became decisions we could leave open until we had better information.

The first version became smaller. But it also became more useful.

Its job was no longer to demonstrate that we had designed the right product. Its job was to tell us whether our most important assumptions survived contact with reality.

That changed the emotional relationship I had with an imperfect product. Previously, incompleteness felt like weakness. Now it could be deliberate.

If a feature was missing but its absence prevented us from answering an important question, it mattered. If a feature was polished but did not help us learn anything, it could wait.

This sounds like a product-management distinction. For me, it became something much more fundamental.

I stopped seeing the first version as the beginning of the final product. I started seeing it as an instrument for finding the final product.

Reality Became Part of the Process

Once people could actually use what we had built, our conversations changed. Before release, we talked about possibilities. After release, we could talk about behavior.

That difference was enormous.

People ignored things we had spent weeks designing. They returned to parts of the product we had considered secondary. They interpreted language differently from how we intended it. They created workflows we had never imagined. Sometimes they found better ways to use the product than we had designed. Sometimes they exposed flaws that were impossible to see from inside the company.

The natural instinct in those moments is to explain. We had designed the feature correctly. The user misunderstood it. They had not followed the intended flow. They had not understood what the product was trying to do.

That instinct is dangerous.

If several people misunderstand something in the same way, the question is rarely whether several people independently failed to understand the product. The more useful question is why the product required an explanation.

That shift changed how I interpreted feedback. I became less interested in what people said they liked and more interested in what they actually did.

A compliment can be encouraging. Repeated behavior is evidence.

Someone telling you that they love an idea is interesting. Someone changing their workflow because of your product is much more interesting. Someone paying for it, returning to it, recommending it, or abandoning it tells you something even more valuable.

The product became a source of information that existed outside our own assumptions. And once that information existed, ignoring it became a choice.

I Stopped Trying to Be Right

This was the lesson that stayed with me long after the individual product decisions stopped mattering.

I had originally treated being wrong as a cost. If we spent several weeks building something and discovered that the assumption behind it was incorrect, it felt as though those weeks had been lost. Eventually I began seeing it differently. If those weeks prevented us from spending six months building the wrong thing, they were not wasted. They were cheap information.

That changed the way I thought about iteration. The purpose of an experiment is not to confirm that you are right. Sometimes its greatest value is proving that you are wrong before the consequences become expensive.

That requires a different kind of discipline. You have to be willing to design tests that could genuinely disprove your assumptions. You have to ask questions whose answers might force you to change the roadmap. You have to separate the emotional attachment you have to an idea from the evidence supporting it.

Most importantly, you have to understand that changing your mind is not automatically a sign that you lacked conviction. Sometimes it is evidence that you learned something.

There is a difference between having no strategy and remaining responsive to evidence. A company that changes direction every time someone has a new idea will never develop coherence. A company that refuses to change direction after reality has clearly contradicted its assumptions will eventually mistake stubbornness for conviction.

The difficult part is knowing what should remain fixed and what should remain open. The purpose of the company can remain stable while the product changes. The customer problem can remain stable while the solution changes. The underlying insight can remain stable while the business model changes. The roadmap should be allowed to move.

That became one of the most important distinctions I learned as a founder.

Conclusion

I used to think that strong founders were the people who could see the destination clearly and then execute their way toward it.

I don't think that anymore.

The further I get into building, the more I believe that the important skill is not predicting the entire path. It is knowing how to take the next step while remaining capable of changing your mind about the one after it.

The companies that eventually become large and complicated still begin with the same uncomfortable reality: at the beginning, you know very little. You know what you believe. You know what you hope is true. You know what you are willing to test. The rest has to be discovered.

That changed what I think a good first version is supposed to accomplish. It does not need to prove that the original idea was brilliant. It does not need to contain everything the company might eventually become. It needs to create enough reality that you can learn something you could not have learned by thinking about it.

That is a much more demanding standard than simply shipping. And it is also a much more useful one.

I no longer ask whether the first version is right. I ask whether it is capable of making the next version smarter.

Continue reading

The Product Wasn't the Business

Tools Shape Products

Build Before You Know

Build Before You Know

Overview

Intoduction

Intoduction

The Problem With Being Prepared

The First Release Was a Question

Reality Became Part of the Process

I Stopped Trying to Be Right

Conclusion

Continue reading

Contact

Contact

Contact