# Why I Stopped Running Projects > Project-led organizations build things that end. The shift to durable product teams changes what gets built, who owns it, and how fast an organization can... Published: 2025-07-08 · Updated: 2026-06-23 · Topics: Digital Transformation, Product Strategy & Development, Team Building & Culture, Growth Leadership, Agile Methodologies · Author: Alan Wizemann The trouble with projects, the thing I kept running into for years before I could name it cleanly, is that they end, and the uncomfortable truth is that not everything should. The checkout flow your customers use every day should not end, the personalized homepage that surfaces the right product to the right buyer should not end, and the experience that gets an order confirmed to a bar manager at eleven in the evening should not end either. These are things that need someone responsible for them continuously, watching them, adjusting, improving, and responding to what the data is actually showing rather than to what someone assumed at the outset. A project, by contrast, has a scope, a timeline, and a due date. Once those three things are satisfied the work is simply declared done. The team disperses, and what they built gets handed off to whoever is responsible for maintenance (which in practice is usually nobody in particular, because maintenance was never in the original budget). Six months later the product has small failures that no one owns, while everyone quietly wonders why the platform feels like it was built by people who never had to use it. I have been through that cycle enough times that I eventually stopped accepting it as a normal cost of doing business. The model I have moved to is what I call a durable team, though in most tech circles you will hear it described as a product team model, and the principle underneath both names is the same: a fully funded, dedicated team that is responsible for a specific product or experience and is not tied to a due date. Their job is simply to make the thing better, continuously. Their goals get set around the success of what they are building rather than around the satisfaction of a delivery milestone. At Southern Glazer's we have somewhere between six hundred and seven hundred people working across the digital and technology organizations who are arranged this way. One of those teams does nothing at all but work on cart and checkout for the Proof platform – that is the entirety of their focus. They track cart completion rates daily, sometimes hourly, so that when a new feature ships they know within days whether it is actually working, and when it is not, they fix it. Nobody declares the project done and reassigns the team to something shinier, because there is no end date on the checkout experience, and there was never meant to be one. That single example captures most of what changes when you move from projects to products. A project team is optimized to ship, and a product team is optimized to improve. While those two orientations look almost identical on a slide, they diverge sharply in what actually gets built and maintained over time. Project teams hit their milestones; product teams ask whether the milestone was even the right thing to build in the first place, and then keep asking that same question long after it has shipped. Something shifts in the people on these teams when the structure is right, too. When a team has a clear product mission and enough organizational support to operate against it, the work genuinely feels different – there is no countdown to a project end date, there is no open question about what happens after launch, and the team simply owns the thing. That ownership changes how people think about quality, for the straightforward reason that they are the ones who will still be looking at the results six months from now. People build differently when they cannot hand the consequences to someone else. The harder part of all this is what has to be true underneath the durable team model for it to actually function, and we call that piece a single pane of glass: every team's roadmap, goals, budget, and timeline made visible in one connected place. When a large infrastructure change is going to affect the data structures the recommendation engine depends on, the team building that engine needs to know months in advance and not weeks. When a new supplier relationship opens up in a market, the teams that build the customer-facing experience there need time to react rather than to scramble. Without that shared visibility, durable teams quietly become isolated silos with a friendlier name, where the structure has changed but the behavior has not, and you discover that you have renamed your problems instead of solving them. Building that foundation was, frankly, the least exciting phase of the entire transformation – unifying tools, standardizing how teams report progress, getting budget tracking and goal-setting and team measurement all working from the same system. It took longer than anyone wanted while producing nothing a customer would ever see. But without it, everything else would have been slower and more brittle, and the coordination costs alone would have eaten most of the speed gains we were trying to capture. Once the foundation matures, what becomes possible is a kind of speed that compounds, and I want to be careful to distinguish it from the startup-style speed of shipping fast and patching it later. This is organizational speed, the kind you get from teams that know exactly what they are optimizing for, have the data in front of them to see whether they are moving in the right direction, and hold enough authority to make decisions against that data without escalating every step up the chain. When something changes in the market or in the customer base, those teams can respond. That is precisely because they are not locked into a plan that was written six months earlier and is now defended out of habit. The other thing that shifts is how goals get set, and this one took me a while to fully trust: we do not goal product teams on revenue, because revenue is a trailing indicator, the thing that appears after you have done the right things rather than while you are in the middle of doing them. We goal teams instead on customer outcomes – satisfaction scores, platform speed, the ease of finding a product, the accuracy of what arrives on the truck – and when those move in the right direction, revenue follows. That sequence is genuinely the point. Put the revenue goal on top and you get teams optimizing toward a metric rather than building something people actually want to use, and those two things look alike on a roadmap right up until they diverge sharply in the results. Projects end, and products do not. In the end my whole argument comes down to that distinction: if the work matters to the customers who depend on it, then it deserves a team that is going to be there when it needs to change. --- Canonical: https://alanwizemann.com/articles/why-i-stopped-running-projects