It Started as a Whiteboard Sketch

The multi-location inventory system did not start with a PRD.

It started with a question from a seller during a research call: “I have three warehouses. Why can I only list my stock from one?”

That question sat in my notes for two weeks. I kept coming back to it because it exposed a structural limitation in the platform, not a feature gap. The platform assumed every seller operated from a single location. That assumption was baked into the data model, the checkout flow, the fulfillment routing, and the pricing engine.

One question. Four systems that needed to change.

The whiteboard session

I booked a meeting room with two engineering leads and drew the current data model on the whiteboard. Single location per seller. Stock tied to the seller entity, not to a location entity. Fulfillment routing had no concept of “which warehouse is closest to the buyer.”

Then I drew what the model needed to look like. Location as a first-class entity. Stock tied to locations, not sellers. Fulfillment routing that could query multiple locations and pick the optimal one.

The gap between the two drawings was the project. Thirty minutes of whiteboarding defined eighteen months of work.

Why zero-to-one is different from optimization

Optimization is about making an existing system better. You have data, benchmarks, and a clear before-and-after. Zero-to-one is about building something that does not exist yet. You have a hypothesis, some user research, and faith that the system will work once it is built.

The multi-location project had no benchmark. There was no “current multi-location performance” to improve. The question was binary: can sellers manage multiple warehouses, or can they not? The answer was no, and we needed to make it yes.

That binary nature changes everything about how you manage the project. You cannot A/B test something that does not exist against something that does. You cannot measure incremental improvement. You ship the foundation, wait for adoption, and then start measuring.

The uncertainty is uncomfortable. You spend months building before you have any signal that it works. The team asks “how do we know this is the right approach?” and the honest answer is “we do not, until sellers start using it.”

What I learned about going from zero to one

Three things:

First, the data model is the product. Everything else — the UI, the seller tools, the onboarding flow — is a consequence of the data model. Get the data model wrong and you rebuild everything. Get it right and the rest follows.

Second, adoption is not automatic. We built the capability and sellers did not immediately flock to it. We had to design onboarding, education, and incentive programs to drive adoption. The “if you build it, they will come” assumption is wrong for infrastructure products.

Third, the whiteboard sketch matters more than the PRD. The PRD is a communication tool. The whiteboard sketch is where the thinking happens. I still start every zero-to-one project with a whiteboard, even if the whiteboard is a digital one.

That thirty-minute session turned into one of the platform’s largest transaction contributors. I keep a photo of the original whiteboard drawing. It reminds me that big outcomes start with simple questions.