You Built the Wrong Thing First

The most expensive mistake in Physical AI is not a bad hire or a missed market window. It is a product that nobody asked for, built by people who were certain they already knew what the customer needed.

It happens the same way every time. The development cycle is long. The engineering is complex. The team reasons that because they will spend 18 months building something, they should build something comprehensive enough to cover every scenario they might encounter in the field. That logic feels responsible. It is the opposite.

What Gets Skipped

The step missing from that reasoning is the one that matters most. Before you decide what to build, you need to know what the customer values. Not what you believe they will value once they see it. What they will pay for, renew, and tell someone else about. Those are different questions, and most Physical AI companies never ask them before the first line of code is written.

The result is a product built at full cost for a set of assumptions that turns out to be about 10% correct. The other 90% is features the customer never requested, complexity that drives up support costs, and development time spent solving problems the market does not have.

I watched a team spend the better part of a year building a version of their product that covered every edge case they could imagine. When they finally deployed, customers used two features consistently. The rest went untouched. The team had the data to know this earlier. They chose not to look for it.

The Simpler Version Always Exists

There is almost always a version of a Physical AI product that is linear, constrained, and capable of proving the core thesis before the full build begins. It does not need to think autonomously across every variable. It needs to demonstrate that the customer has the problem you believe they have, that your approach solves it, and that they will pay you for solving it.

That version is not the product you will sell forever. It is the instrument you use to find out what the product you will sell forever actually needs to be. Most founding teams will not build it. It does not feel ambitious enough. It does not make for a good pitch. Building it feels like admitting you do not yet know the answer.

That is precisely the point.

You Do Not Even Need a Product to Start

The deeper argument is this. You do not need a first build to begin learning what is true. There are things you can put in front of a customer before the product exists that will tell you more about product-market fit than six months of internal development will. A prototype. A simulation. A manual version of the outcome you are promising. Something small and fast that forces the customer to react to a real thing rather than agree with an idea.

Every reaction you get before you build is cheaper than every change you make after. The customer who tells you the feature you spent four months on is not important is doing you a favor. The customer who tells you the feature you have not built yet is the reason they would sign is giving you the roadmap.

It is never too early to begin learning what is true. The companies that treat that learning as the first phase of product development, rather than a distraction from it, are the ones that arrive at market with something the customer recognizes as theirs.

The Question Worth Asking This Week

Before the next sprint starts, before the next feature gets scoped, one question is worth sitting with. What is the smallest thing we could build or show a customer in the next 30 days that would tell us whether we are right?

If the answer takes longer than 30 days, the build is already ahead of the learning. That is the wrong order. The product does not shape the customer. The customer shapes the product. Start there.