Every Business Sits on a Product

If you run a business that makes something, you are sitting on a product, and you almost certainly understand it less precisely than you think you do. That is not an insult. It is the single most useful thing you can know about your own operation, because once you see it, a lot of problems you were treating as separate turn out to be the same problem.

Here is the idea, and it is not really about cabinets even though that is what I happen to build for:

Every manufacturing business sits on a product. If you understand that product at its most granular level, every material, every labor second, every overhead dollar, you can automate everything above it.

Think about what “everything above it” actually contains. Pricing. Quoting. Scheduling. Sales. Marketing. Reporting. You probably treat each of those as its own problem, with its own software and its own headaches. They are not separate problems. They are all functions of product data. Get the product data right and the work above it stops being manual effort and starts being arithmetic. Get it wrong, or skip it because it is boring, and nothing you stack on top of it will hold. So if you only take one thing from this, take the order: the product comes first, and everything else is downstream of how well you understand it.

Start by taking the product apart

The first move is the unglamorous one, and it is the one most people skip. Take the product apart until there is nothing left to take apart. Every material. Every labor step. The time each operation actually takes, not the time you assume it takes. The overhead each unit actually absorbs. You are building a real bill of materials for every variation you sell.

This sounds like data entry, and it is not. Data entry is when you already know the answer and you are just typing it in. Decomposition is where you find out what you only thought you knew. When I did this on my build, one operation I had estimated at roughly twenty minutes turned out, when measured, to take closer to seven. That is not a rounding error. That is a threefold mistake that had been quietly mispricing the work for years, and nobody had caught it because nobody had ever forced the product to explain itself. You will have one of these too. Everyone does. The only question is whether you find it, or whether your customers keep paying for it in one direction and you keep eating it in the other.

So here is the test for whether you have actually done this phase, and it is a strict one. Hand your product documentation to someone with zero context. If they cannot arrive at a rough cost from what you gave them, you are not done. The gap they hit is the gap that everything above will inherit. Do not build pricing, or quoting, or anything clever on top of a foundation that cannot pass that test. You will just be automating your guesses, faster. (If you want the longer version of why the boring data has to come before the clever layer, I wrote about that exact mistake separately.)

Eight phases, each one standing on the last

Once the product is decomposed, the system builds up in eight phases, and the order is not arbitrary. The first four are the foundation, and they are strictly sequential: formulate the product, map the operation that produces it, put all of it in one relational database so nothing lives in a silo, and capture the knowledge that currently survives only in people’s heads. The next three turn that foundation into a working commercial engine. The last one turns the whole thing outward, to the market.

I will not walk all eight here, because the framework page does that properly, with the theory each phase rests on and an honest account of what is actually built. What is worth your attention is the shape, because the shape is the part almost everyone gets wrong, and getting it wrong is the difference between a pile of tools and a system.

The part almost everyone gets wrong: 5 to 7 is a loop

Look at phases five, six, and seven: project intelligence, quoting, and sales. If you are like most people, you will read those as a pipeline. Track the work, price the next job, sell it. Left to right, done. Build them that way and you will get three tools that each do their job and never talk to each other.

They are not a pipeline. They are a triangle, and the data is supposed to run both ways around it.

• 07 ⇄ 05A change order books a new factory project; its real production costs flow back as profitability.
• 05 ⇄ 06Actual costs correct the estimates, so the next quote lands closer to reality.
• 06 ⇄ 07Every quote is a promise sales makes about cost, capacity, and timeline.

Watch how it actually moves. A change order in sales books a new project on the factory floor. That project produces real costs, measured, not estimated. Those costs flow back two directions at once: they correct the profitability of the job you just did, and they sharpen the estimate for the next one, so the quote that produced the change order gets a little less wrong every time the loop closes. Production truth, quote accuracy, and sales promises end up continuously correcting each other.

This is the whole difference between “I built some tools” and “I designed an intelligence layer,” and it is worth being able to tell which one you are doing. A linear framework is a checklist: you do the steps and you are finished. A system with feedback loops is an architecture: it gets measurably smarter the longer it runs, because every closed project is a test of its own accuracy. If you want the second one, you have to wire the loop deliberately, because it will not happen on its own. Left alone, software flows in one direction.

That is also why I split the methodology in two. The Build gets you the system once. The Run is what a team does with it every day afterward to keep the loop closing, because a loop that nobody tends quietly goes slack. And before you write a line of code for any phase, there is a set of questions you have to answer honestly about your own operation. Those live in the Navigator, and they are worth more than the code, because the code is easy once the answers are real.

When you get this right, marketing is just publishing

Phase eight is content and marketing, and it is the one I am in now, which makes the premise almost uncomfortable to admit: if the first seven phases are done right, marketing stops being a creative act too. The project photos already exist. The specs already exist. The results already exist. You are assembling what the system already knows, not inventing a story to cover for the fact that you do not know it.

Which is exactly what this website is. It is phase eight in action, published from the same data architecture that prices the quotes. And it comes with a built-in honesty check: if you are not proud enough of the underlying work to show it, that is not a marketing problem you can write your way out of. It is a product problem, and the marketing is just telling you the truth about it. So I am showing the work, while it is still being built. (If you want to see the structure that came out the other end, the shape of the system lays it out.)

Where to start

If all of this lands and you want to do something with it, do not start with the impressive part. Do not start with the AI, or the dashboard, or the quoting tool. Start with the product, and take it apart further than feels reasonable, until a stranger could price it from your notes. Everything you want to build later, all of it, is a function of how honestly you do that one boring thing first.

If you want the full blueprint from there, with all eight phases, the theory under each, and where each one actually stands, start with the framework.