Episode 011: Making It Repeatable - Part B

Part A was mostly about keeping the physical business moving: having materials ready, replenishing what sells, keeping equipment available, producing the same product consistently, packaging it correctly and getting it out the door. But once that cycle starts repeating, Operations begins doing something else that is just as valuable. It exposes friction. Something can look completely reasonable when I do it once. The second or third time I may notice that it is slightly awkward. By the twentieth time, I know exactly which step wastes motion, which decision I keep having to remake and which part of the process is more fragile than I originally thought. Those are things Engineering cannot always discover while a product is still a prototype because some information only appears after the design stops being an experiment and becomes work.

That does not mean every irritation deserves an Engineering project or a new company standard. A one-time annoyance may be exactly that. What repetition gives me is evidence about which problems are actually recurring. Five unnecessary minutes barely matter once, but five unnecessary minutes repeated a hundred times is more than eight hours. An awkward assembly step may be perfectly acceptable while I am still proving that a product works, but once the product is established that same step becomes manufacturing friction. An insert that needs a little manual trimming may be harmless on the first shipment, but if I am still doing it on every package months later, I have quietly turned a temporary workaround into a production method.

Operations is not only about repeating the process. It is also the place where the process teaches you how it should change.

That feedback loop is one of the reasons I want to stay close to the actual work even as the Business OS gets more capable. There is a tempting version of the AI story where the goal is eventually to automate enough of the company that I barely have to think about it. I would absolutely like the system to become more agentic over time. I want it to notice more things without waiting for me to ask. I want routine information to move where it belongs automatically. I want outside specialist tools to be usable without turning me into the operator of another application. I want reports, reminders and straightforward follow-up work to require less initiation from me. There is nothing wrong with wanting more automation.

What I do not want is to confuse where I hope this goes with what it is today. The Business OS did not design my products while I watched. It did not walk into the shop, measure an enclosure and decide what needed to change. It does not know when a print looks wrong because it stood there watching it come off the plate. I provide much of that reality. I bring observations, measurements, ideas, constraints, failures and decisions into the system. What the system does extremely well is give those things somewhere to go. It connects them to the right kind of work, helps me reason through them, remembers what was established, surfaces conflicts and creates a structure that is increasingly difficult for me to maintain purely in my head.

That may sound less exciting than saying AI runs the company, but it has been far more useful. The biggest change so far has not been automation. It has been order. Engineering has somewhere to do Engineering work. Operations has somewhere to carry Operations. Decisions have owners. A problem discovered in one part of the business can move deliberately into another instead of becoming a half-remembered note. Established knowledge has somewhere to live. Important work gets surfaced instead of disappearing into whichever conversation happened to be open when I thought of it. Even the daily CEO updates are part of that. I am still the person who ultimately knows and runs the business, but I no longer have to rebuild the state of every department from memory just to understand where things stand. There is a much larger story in that executive layer that I will probably come back to later in this series, because it turns out that even when every department reports to the same person, accountability still matters.

This is not a magic pill. The system can help me carry the business, but I still have to build the business.

I have already seen how important that distinction is because the Business OS can be wrong. During an Engineering discussion, the system once began talking about an established specification as though it were still merely one possible option. The reasoning around it was not necessarily bad, but it started from the wrong place. I caught it because I knew the product and knew the decision had already been made. That exposed a weakness in the system: it was beginning to reason about a change before clearly identifying the current baseline.

So we changed the rule. When a discussion involves an established specification, the Business OS now has to anchor itself to the current baseline first, then identify the proposed change, the difference between the two and whatever remains unknown. That safeguard did not come from the AI autonomously reflecting on its behavior one night and deciding to improve itself. I had to notice the problem. I had to recognize why it mattered. The system then helped turn that observation into a better operating rule.

The same thing has happened repeatedly as I have built the Business OS. I started with a fairly simple need: different kinds of work needed different places to live. Engineering was not Operations. Sales and Marketing was different from Business Development. Established company knowledge needed somewhere more durable than an old conversation. That structure solved real problems, and then actual use exposed the next set of problems. Chats became long enough that they could not realistically remain the authoritative memory of the company, so working conversations and governed files became separate things. Transfers between departments helped preserve ownership, but then I discovered that the system could overdo them and create more administrative work than the problem deserved, so we tightened the rules. Morning check-ins created a useful daily rhythm, but then I discovered the written standard did not actually make the CEO Dashboard update requirement explicit enough, so departments began skipping it. Again, the answer was not to tell myself to remember the missing step. The answer was to fix the system.

That pattern is becoming one of the most important lessons of this entire project. I am building JW Designs while also building the Business OS that helps me run JW Designs, and both of them are being improved by the same thing: actual use. There is no perfect master architecture that I somehow failed to design on day one. I can build a reasonable structure, use it, see where it creates friction and change it. The important part is making sure each change actually removes more work than it creates. A system that saves me ten minutes but adds fifteen minutes of maintenance is not an improvement. A process that requires me to keep several versions of the same truth synchronized is not reducing cognitive load. An external tool that gives me a useful answer but turns me into the full-time operator of another application may not be helping either.

The system helps me remember. It does not give me permission to stop paying attention.

A recent experiment made that evolution especially obvious. I wanted to see whether a specialist 3D-print costing application could do something materially better than the Business OS could do itself. Before letting the specialist influence anything, we built our own calculation from a synthetic dataset. Then we gave that same anonymized information to ChatGPT Work and had it operate the external application. I did not sit there opening fields and typing numbers into someone else's calculator. Work navigated the application, entered the information, documented the assumptions, extracted the results and brought everything back for comparison.

The results were remarkably close. Our internal calculation and the purpose-built specialist landed within cents and fractions of a percentage point on several of the important outputs. The specialist did have a more refined way of handling one part of failure costing, and we learned from it. That alone was encouraging because it showed that the Business OS was not simply producing plausible-looking numbers. We understood the model well enough to get very close independently, understand why the remaining difference existed and improve our own approach with something useful the specialist exposed.

But the part I found even more interesting was how the experiment happened. A year earlier, that exact workflow was not available to me. ChatGPT itself is becoming more capable while I am building the Business OS around it. Something that once would have required the system to tell me what to click and then leave me to operate another application can increasingly be handled by the system itself. The Business OS is therefore evolving in two directions at once. I am feeding it more business knowledge, better standards and clearer operating rules, while the technology underneath it is becoming capable of doing more with that structure.

That matters to the architecture. I do not want to redesign JW Designs every time ChatGPT gains another capability. The organizational structure should remain relatively stable while the tools underneath it improve. A year ago, the system might have helped me evaluate a specialist calculator and prepared the numbers for me to enter. Today it can increasingly be the hands that operate the specialist application. Tomorrow there may be more parts of the workflow that move from assisted to genuinely agentic. The Business OS gives those changing capabilities somewhere coherent to plug in.

This also changes how I think about outside software. The Business OS does not need to become the world's best 3D-print calculator, marketing platform, accounting package, research database and every other specialist application at once. A specialist can remain good at its specialty. The Business OS can decide when that specialty is useful, provide only the information required, bring the result back into the larger business context and preserve the actual decision inside JW Designs. In the costing test, we even kept the external data synthetic because there was no reason to hand another application real business information merely to see whether its math was useful. That is the kind of relationship I want with outside systems: useful when needed, replaceable when not, and never the only place the company understands its own business.

The same principle explains why the boundaries between Engineering and Operations matter even though the person working in both departments is still me. Operations is going to discover Engineering problems. A part may be technically adequate but awkward to manufacture. A product can work perfectly on the bench and reveal a weakness after repeated shipping. A design change can solve one problem and unexpectedly create another in packaging or assembly. Operations should capture those observations because that is where the evidence appears. What it should not do is quietly redesign the product simply because a different idea feels easier while I am standing at the bench.

That may sound excessively formal for a one-person company, but it solves a very human problem. Without the boundary, I can make a change while building something, decide that it works, continue with my day and two weeks later have to reconstruct whether that was an experiment or the new official version. I do not need permission from myself to make a change. I need the business to be able to distinguish between an observation, an experiment and the current standard. Operations can find the problem. Engineering can own the design response. I still do the physical thinking, modeling, testing and judgment required to solve it, but the work has a deliberate place to happen. Once the revised answer proves itself, Operations can depend on it and the durable knowledge can move into the Company Wiki.

The departments are not there because I need permission from myself. They are there so the business can tell the difference between an observation, an experiment and the current standard.

That progression is becoming increasingly important because a successful improvement eventually has to stop being a story I remember. I do not want manufacturing instructions that amount to, “This is the one where I changed something after that damaged shipment,” or “I think I decided to use the other method on these.” Those shortcuts are incredibly easy to accumulate in a one-person business because the person who discovered the lesson is the same person doing the work later. For a while, memory feels faster than documentation. I know what happened, so why spend time writing it down? The problem is that I only know what happened while that information remains near the front of my mind. A month later it is competing with dozens of other Engineering decisions, customer conversations, purchases, design changes, production issues, marketing ideas and everything else happening inside and outside the business.

The flow I am trying to establish is simple enough: an idea gets used, Operations observes what actually happens, the method gets refined if necessary and, once it becomes the accepted way JW Designs does something, the current answer gets preserved. Not every experiment deserves to become a standard. Something can work once and still need more validation. A workaround can remain temporary. A process can be perfectly fine for today's volume without being appropriate forever. But once I am depending on something as the normal way the business operates, I need somewhere more reliable than my memory to keep it.

Standards stop being documentation when Operations starts depending on them.

That brings the Operations story back to the reason I began building the Business OS at all. Running JW Designs means moving constantly between different kinds of work. I can be solving an Engineering problem, fulfilling an order, checking supplies, answering a customer, adjusting a Shopify page and then going back to something that has been printing for six hours. Every one of those tasks is manageable. The difficult part is the accumulation. What needs to be replenished? What material is getting low? Which packaging revision am I using? What changed on that product? What failed the last time I shipped one? What machine is occupied? What needs to happen before the next order? Which issue can wait until tomorrow? None of those facts necessarily deserve permanent space in my head, but without some other system they keep trying to occupy it anyway.

And JW Designs is not the only thing in my life. I have a full-time career. I have family, a house, animals, hobbies and all of the ordinary things that continue happening whether there is a business to run or not. That is part of the small-business conversation that gets lost when everything is framed around hustle and productivity. There is a finite amount of attention. The solution cannot simply be to pay attention harder. What I need is the ability to leave part of the business, know that the current state has somewhere to live, and come back without rebuilding the entire context from memory.

That is what the Business OS is gradually becoming. It is not replacing me. I am still the person making the decisions, catching bad assumptions, working in the shop and deciding when a process is good enough to become the standard. What it gives me today is organization, accountability and continuity across all of the different functions that otherwise have to coexist inside one person. The daily updates, departmental ownership and executive view are part of that structure too, and there is probably an entire future article in why reporting to yourself turns out to be surprisingly useful when you are also every department in the company.

The goal was never to make myself unnecessary. It was to stop requiring myself to remember everything at once.

Operations has also made me much more comfortable with the idea that “standard” does not mean “finished forever.” A packaging method can be completely valid today and need to change when I introduce a larger product. A replenishment process can work perfectly at current volume and become annoying if sales triple. A printer fleet can have plenty of capacity today and become the bottleneck next year. Even a Business OS rule can solve one problem and later expose another. The point of documenting the current answer is not to freeze the company. It is to keep change from becoming chaos. If something changes, I want to know what changed, why it changed and whether it has actually earned the right to replace what came before.

That is what repeatability has come to mean for me. Not rigidity and not finality. It means having enough confidence in the current process that I can stop carrying it mentally and turn my attention somewhere else. Engineering helps me work through what I should build. Operations helps me make it consistently, improve the process when reality teaches me something new and preserve those lessons so I do not have to keep learning them over and over again. The Business OS gives all of that work some order and accountability while I remain firmly in the middle of actually running the company.

And once I can do all of that, the business runs directly into its next problem. I can design the right product. I can make it consistently. I can package it correctly. I can ship it on time. I can improve the process when something goes wrong.

None of that matters if the people who need it never find it.

Next: Episode 012 — If Nobody Knows It Exists