Products, Not Projects
Every serial builder has an ambition that never quite arrives.
Prefab at scale. A digital handover that someone actually opens. Buildings that get faster instead of starting over. The intent is real. The budget is usually there. And then building seven comes in looking a lot like building one — delivered by people relearning what the last team already knew.
Ask why, and you'll hear about the tools. The market. This particular GC.
The real reason is quieter. Nothing carries. You run each building as its own project, so each building starts from scratch, and a thing that starts from scratch every time cannot get better.
The weeds
Three things go wrong. They're the same thing wearing different clothes.
The lessons don't stick — every project pays again for what the last one already learned. The knowledge dies at the handover — the closeout binder no one opens, the model gone stale by spring, the team scattered the week the doors open. And the authority resets — new building, new GC, new design team, and everything you'd figured out about how you build gets argued from zero all over again.
That's the mud. And here's the part worth sitting with: you don't get out by working harder down in it. You get out by not starting there every time.
Stabilize before you scale
This is a borrowed idea. It comes from the factory floor, and it's older than any of us.
You can't scale something that isn't stable. Push more volume, more speed, more sophistication onto a shaky process and you don't get improvement. You get the same breakage, faster and more expensive.
A portfolio of disconnected projects is shaky by design. There's no baseline to build on, because the baseline gets thrown out and rebuilt every time. So the innovation push stalls — not because the ambition was wrong, but because it came in the wrong order. You reached for scale before you had anything stable to scale from.
Product, not project, is just fixing that order. You treat the way you build as the thing you're building. The standard that stays. The requirements that carry forward. The accountability that doesn't evaporate when the next GC signs.
Then building seven starts on the ground building six left standing. That's stability. Everything you wanted was waiting on the other side of it.
The empty seat
Which leaves one question.
Across the whole portfolio — not one job, all of them — who owns the thing that carries what works from one building to the next?
Reach for the answer and watch it slip. The GC owns his project and leaves. The program manager owns schedule and budget, not the model. The last consultant owned a deliverable that shipped and closed. Every one of them is tied to a project. Every one resets when the project ends.
So no one owns it. Not because anyone dropped it — because the seat was never filled. It sits empty by default.
Leave it empty and you've chosen projects over product without ever deciding to. The buildings still go up. They just never get any better.
If you build the same kind of thing more than once, the way you build it is the asset. The only question is who owns it.