The /Goal

While Jensen Huang is talking about token factories and Steve Yegge is building Gas City to let anyone build their own dark factory with a focus on maximizing token output, more often I am going back to a foundational text for understanding how factories work: The Goal, by Eliyahu Goldratt. The important system when modernizing any existing workflow is not just the token factory - it is the end-to-end workflows for creating value and driving business impact. For everything from manufacturing a widget to building new product features or creating new content, opportunities enabled by AI do not remove the need to think from first principles.

The Goal is structured around the Theory of Constraints. A key learning from this theory is that a system’s output is governed by one bottleneck at a time. On the factory floor a bottleneck might be obvious - waiting on a key input, one machine running at full capacity while others sit idle, or completed work piling up waiting to be delivered to customers. The same can be true in digital product development, if you know where to look. Jira tickets piling up for a specific team or experiment results waiting to be actioned on are common examples - but the calendar of a key approver, or the training cycle for sales and customer support teams might be the real indicator of the bottleneck. Just as often the bottleneck is not being measured - a deep product backlog without high confidence prioritization might be a sign UX research and talking to customers is the real bottleneck, or lack of adoption of a new feature might be a result of bottlenecks in go-to-market activities. Goldratt’s line is that people behave the way they’re measured, so the constraint often hides somewhere not being tracked.

The Theory of Constraints tells us that if we optimize any aspect of our factory that is not the bottleneck, we are not actually driving any business impact. So step one when identifying AI acceleration opportunities for any organization or system has to be identifying where the bottleneck is - or where it will be. Goldratt’s lesson is that relieving your current constraint relocates it. The trap is worse than wasted effort. Flood the org with code when it isn’t your bottleneck, and you’ve just created more unnecessary work-in-progress. Backlogs will grow elsewhere, like review, integration, and go-to-market. You haven’t sped up value creation, you’ve just piled up inventory that isn’t getting to customers any faster.

I too often see AI-pilled, motivated, and talented professionals skip this key step. They are used to living in a world where engineers - and code output - are the limited resource. Fighting for engineering headcount has made them assume this is where the constraint will always be. However, if you believe in the benefits of AI for software development (and I do - my GitHub account has seen more activity in the past 8 months than the prior 8 years), then the last thing you need is more people pushing code. If you blindly start pushing everyone to start vibe coding their own solutions, or if your product managers are spending time pushing code for the first time in years, realize that you are not going to see any benefit if you are accelerating any activity that isn’t your bottleneck.

If you want to leverage AI to move faster, first find the constraint. Accelerate that, and only that, until it moves somewhere else. Then repeat - that’s the whole job. The factory metaphor is fun, but your customers don’t care about you maximizing token output.

The Goal earned its spot on my reading lists – you’ll find it (with company) on New to PM and the CIS 9000 pre-reads.