Leaders Share How They Decide When to End a Project That Is Not Working

I killed a profitable project once because I realized I was optimizing for revenue instead of momentum. We had this fulfillment add-on service generating about $40K monthly, decent margins, clients loved it. But it required constant manual intervention from my best ops manager. Every month I told myself we’d automate it next quarter. A year went by.

The decision rule that finally worked for me: I started tracking what I called “founder energy drain versus growth contribution.” Sounds corporate but it’s simple. Every two weeks I’d write down which projects made me excited to problem-solve versus which ones made me procrastinate opening Slack. The fulfillment add-on? Always in the procrastination column. Meanwhile it was consuming 30% of our operational capacity but delivering maybe 4% of revenue growth.

The moment it became crystal clear was when we lost a major client opportunity because my ops manager was too buried in this side project to handle onboarding properly. We’d been showing progress on the add-on, hitting our internal metrics, client retention was solid. But progress on the wrong thing is just expensive distraction.

Here’s what I wish someone had told me earlier: if you’re celebrating small wins on a project while your main business is starving for attention, you’re already done, you just haven’t admitted it yet. The real question isn’t whether something is working, it’s whether it’s working hard enough to justify what you’re NOT doing because of it.

With Fulfill.com, I use a simpler test now. If a feature or initiative doesn’t directly help brands find better 3PLs faster, it goes in the parking lot. Doesn’t matter if it’s “showing progress.” I learned that lesson the expensive way. When you’re building something, opportunity cost kills more companies than bad ideas ever will.

Shut down that add-on service in a single week. Clients were annoyed for about ten days. Six months later we’d grown core revenue 40% with the same team size.

The decision rule I use is what I call the “two-condition test”: a project earns a pivot when something we control is the primary cause of underperformance, and it earns a shutdown when the evidence consistently points to a market or fit problem we cannot solve.

Most founders struggle with this decision because they default to optimism — there’s always one more thing you could try. The rule forces intellectual honesty by requiring you to explicitly name what you believe will change and why.

The moment that made the call clear for me on a product line we eventually discontinued: we had been running a premium bag configuration for a niche commercial segment for about 18 months. Revenue was low but not zero. The team kept proposing iterations — different materials, different price points, different channels. Each iteration had a plausible rationale. Each one added complexity without improving the underlying performance metric.

I applied the test: is the problem something we control? After mapping it honestly, the answer was no. The segment’s purchasing behavior was driven by procurement processes and specifications we couldn’t meaningfully influence. No iteration would change that. We weren’t going to out-iterate a structural constraint.

We shut it down and reallocated to a segment where our efforts had demonstrable leverage. The decision freed up resources that generated better returns within two quarters.

The rule of thumb I now apply: if your last three attempts to improve performance all addressed different problems, you don’t have a project problem. You have a fit problem.

Deciding whether to pivot or shut down a long-running project often comes down to looking at what happens when the product hits reality. At Distribute, we spent a lot of time working toward fully frictionless outbound campaign automation. We built a feature that let users set up highly complex routing rules with a one-click launch. It showed a lot of technical progress, but it kept missing the mark for the actual users. Giving people an open interface to feed an AI engine messy data just scaled their mistakes faster. They were sending automated emails with “Inc.” or “LLC” still attached to company names, and our team was the one fielding the support tickets when their campaigns tanked.

The decision rule that finally made the call clear for me was our five-minute whiteboard test. If a user’s data routing is too convoluted for us to manually map out on a whiteboard in under five minutes, we stop building UI for it. The one-click launch failed that test completely.

The sheer volume of support tickets, combined with failing that simple whiteboard rule, told us we had to pivot away from frictionless automation entirely. We redesigned the user journey to replace the one-click feature with a forced manual review step. Adding that deliberate friction meant a human–usually a virtual assistant–had to pause and catch the weird edge cases algorithms still miss. Once our users watched their daily hard bounce rates drop to almost zero, no one asked for the fully automated feature back.

Coming from education where we’ve spent 30 years refining our Access to Higher Education courses, I’ve learned this: if the core problem you’re solving is still real and your students are still showing up, you pivot. If engagement drops and you’re chasing ghosts, you shut it down. The decision rule that’s never failed me is tracking active intent versus passive disappointment. When we launched our Advanced British International Diplomas for non-UK students, early completion rates were terrible, but inquiries kept flooding in and students told us the pathway itself was essential; they just needed better scaffolding. That’s a pivot signal. Contrast that with a digital mentoring feature we tried years ago: usage fell off a cliff after the first month, and when we asked why, students shrugged. No passion, no problem worth solving. We killed it in three months. If people care enough to complain or keep trying despite friction, fix the execution. If they quietly disappear, respect that message and move on.

When a long-running project shows progress but keeps missing the mark, I rely on a simple weekly ritual to force a clear decision. Every Friday we run a 30-minute joint review with both teams and score a random sample of 25 recent items against a four-line rubric. The rubric checks that the item maps to one of our four ICPs, shows an active project or hiring signal in the last 90 days, has a defined pain our service solves, and includes at least one bidirectional touch in the past 21 days. All four criteria must be present for a pass and disagreements are logged as rubric refinements, not personal arguments.

Over eight weeks across our 42-operator cohort that routine raised sales-accept rate from 41 percent to 84 percent and held discovery-call conversion at 38 percent versus 17 percent under the old MQL definition. The decision moment for me is when the weekly sample keeps failing that all-or-nothing test despite refinements; at that point we either pivot with a targeted plan tied to the failed criterion or shut the effort down to stop wasting resources.

Deciding whether to pivot or kill a long-running internal tool in a fast-moving digital agency is determined by how quickly our clients are able to receive their deliverables.

It took us approximately six months to develop an internally built automated reporting dashboard for our SEO and web clients. Although we had seen technical advancements with the tool, it was unable to provide stable API connections. Therefore, we were forced to have our strategists manually verify the accuracy of each piece of information entered into the system.

I use the following criteria to make decisions regarding internal tools: they should increase the velocity at which client value can be delivered and should never slow down client deliveries.

I reached my point of clarity on this issue when one of our major campaigns experienced a delay in receiving its campaign reports due to a data sync crashing our custom-built dashboard.

At that time, we immediately terminated our development of the custom-built platform and implemented an existing enterprise-level reporting solution.

Ultimately, preserving our operational velocity, protecting the trust of our clients, and refocusing the efforts of our engineers toward driving search engine results and maintaining site performance allowed us to achieve success through this decision.

My rule is a 90 day window with one measurable metric. If a project shows progress on the thing that actually matters to the business within 90 days, it gets another cycle. If it is only showing “activity” but the core number has not moved, it is time to either pivot hard or shut it down.

We hit this exact situation at Simply Noted with a product line we tried to launch for the wedding market. Custom handwritten invitations using our robotic systems. The idea made sense on paper. We had the hardware, the handwriting technology, and demand seemed real based on search volume.

Six months in, we had a beautiful product page, sample kits, and a handful of orders. But the metric that mattered, repeat purchase rate and average order value, was terrible. Wedding customers buy once and disappear. Meanwhile, our B2B clients in real estate, insurance, and nonprofits were reordering every month.

The moment that made the call clear was when I looked at the revenue per hour our team was spending on wedding orders versus B2B fulfillment. It was not even close. We were spending three times the support hours on wedding clients for a fraction of the lifetime value.

We shut the wedding line down within a week of that analysis. Redirected the team back to B2B, and the next quarter was our best ever. Sometimes the hardest projects to kill are the ones that feel like they should work.

Progress without results is just motion. In real estate, you can show 40 houses and feel busy, but if nothing is closing, something is broken.

My rule is simple. I ask whether the fundamentals are wrong or whether the execution is wrong. Those are two very different problems.

If the market shifted and the strategy no longer fits, that’s a fundamentals problem. No amount of harder work fixes that. You pivot or you stop.

If the plan is sound but the process has holes, that’s fixable. You adjust and keep going.

The clearest moment I had was with a marketing approach we ran for about a year. The leads were coming in. The numbers looked decent on paper. But the quality was poor, and our agents were burning time on people who weren’t ready to buy or sell.

We kept telling ourselves it was improving. It wasn’t. It was producing just enough to justify keeping it alive.

I finally asked the team one question. If we started this today knowing what we know now, would we do it? Nobody said yes. We cut it the next week.

That question is the cleanest decision rule I know. It strips out the sunk cost thinking and forces an honest answer.

Momentum feels like progress. Sometimes it isn’t.

I give a project three consecutive review cycles where I’m measuring the same core metric. If that metric is moving up but the gap between where it is and where it needs to be stays constant cycle over cycle, the project gets shut down.

The moment that made this concrete for me was a product launch I kept alive for nearly a year. Every month my team would show me growth numbers, and they looked fine in isolation. But when I lined up the delta between actual and target month over month, the gap was basically flat. We were gaining ground in absolute terms, but the distance to the target was holding steady.

I pulled the plug and redirected my team’s hours into a project that had been starved for attention. That second project hit its benchmark within two months.

Deciding to cut or shift a project comes down to one core metric: alignment with your promise of balance. In our small-batch roastery at Equipoise Coffee, we prioritize ruthlessly because our resources must focus on what we do best: sourcing high-quality beans and applying precise roasting science to eliminate bitterness.

My go-to decision rule is the Resource Tax vs. Core Value test. When we’re developing a new roast profile or working on an educational guide for our home brewers, we track how much energy is diverted from our daily standard of excellence. If a project requires constant, exhausting adjustments just to reach baseline quality, we don’t pivot; we shut it down.

Pivoting requires a clear, adjacent path. If you’re constantly fixing mistakes rather than steering toward a new opportunity, you’re not pivoting; you’re just dragging out a slow decline. We’ve learned that clear communication is the fastest way to build trust, both with our customers in Harlingen and within our own team. We don’t hide behind hope when a project isn’t working. We explain the tradeoffs openly, pull the plug, and redirect those tight resources back to what we know works, like perfecting our signature blends or sourcing single-origin gems like Mexican La Laja Honey.

If a project doesn’t serve the primary ritual of a smooth, mindful morning cup, it won’t get a second chance from us. You have to trust your data, protect your team’s focus, and remember that stopping an underperforming project is actually a massive win for your business. It frees you up to deliver the quality your audience expects.

When a long running project shows activity but keeps missing the mark, I use one simple rule: if the next 6 to 8 weeks will only produce more output, but not a meaningful new signal, it is time to stop or make a real pivot. Progress is not the same as traction. Shipping features, publishing content, and improving workflows can look productive, but if the same users are not coming back, converting, or referring others, the project is teaching you very little.

As a founder, the clearest moment is usually when the team starts defending effort instead of evidence. If the update sounds like, “we built a lot,” rather than, “this metric changed because of this decision,” that is a warning sign. At that point I ask three questions: what assumption are we testing next, how quickly will we know if it worked, and what metric would make us continue with confidence? If we cannot answer those clearly, the project is drifting.

My decision rule is this: pivot when the problem is still real and a small group of users clearly wants the outcome, but your current approach is not getting them there. Shut it down when demand is vague, retention is weak, and each new iteration is just a more polished version of the same miss. In other words, keep the mission, but change the mechanism only if there is still user pull.

In product and content businesses, I have found that the most expensive mistake is not shutting down too early. It is staying in the “almost working” zone for too long because visible effort feels safer than a hard decision. A good project earns the right to keep going by creating sharper learning, stronger user behavior, or both. If it is doing neither, the honest move is to cut it and free up attention for something with clearer signal.

I make the decision to pivot when the project starts to require excessive explanation. I’m not referring to technical clarification, but rather ordinary explanation. The updates sound better to the people working on the project than the people using it. That is a subtle warning sign. Progress should make explaining the idea easier. When it takes five minutes of context in order to point out a single improvement, I start treating that as evidence rather than awkward communication.

The most salient moment I had was when we shipped a better version to everyone, and only people that already knew the backstory were excited by what we had shipped. New users would stop in the same place and misunderstand the same part. That made the decision pretty easy. If the next version only rewards people for being patient with the idea, I pivot. If the pivot depends on people remembering why we started the project, I shut it down.

I’ve spent over twenty years building advanced networking training at INE and consulting with ISP/enterprise teams, so I’ve seen plenty of projects that looked “busy” but weren’t producing capability.

My rule is: if the project is improving activity but not improving the real-world decision the user has to make, pivot hard or stop it. Progress on content, features, or dashboards does not matter if the person still cannot troubleshoot, secure, or operate the environment better.

A clear example is CCIE training. If learners could follow a lecture but failed when placed in an integrated troubleshooting lab, the answer was not “add more slides”; we rebuilt around scenario-based practice because the miss was in application, not information.

For a shutdown call, I look for repeated misses after the core assumption has been tested. If the user problem is still valid, pivot the delivery; if the problem itself no longer maps to operational need, stop funding momentum.

When we have a continuing internal program which is taking longer than expected to meet its main objectives, then I will assess the negative impact it may have on all the office functions downstream from the program. If my rule is followed (and it is), as soon as the delay creates a bottleneck in another department or departments, then the project should be paused. We experienced a time when our internal facility supply tracking tool had been updated with many custom features, and while the project team did make some relatively minor software enhancements, the long-term delays were creating problems for our planned digital updates in our billing records division. It became apparent, when a cross-functional assessment was completed, that one single delayed project was causing both of the other office groups to be at a standstill. We, therefore, stopped working on the customized implementation right away and went back to implementing a much simpler version of the same type of software. At the end of the day, this decision allowed us to free up our facility’s resources internally, remove the “logistical logjam” created by the project, and ultimately keep all of our office schedules intact.

My rule is simple: if the project is still making progress but no longer protects the original business value, it needs to be reset or shut down. Progress by itself is not enough. A team can be busy, shipping pieces, and still be moving farther away from the outcome that justified the work in the first place.

The moment that makes the call clear is usually when the source of truth breaks down. If the story specs, project notes, requirements, or decision history are scattered, the team starts solving from memory instead of from a shared plan. That is when missed targets stop being a people problem and become a system problem.

The fix is to pull the work back to the original intent. What was this supposed to improve? Is that still true? What is it costing now in time, money, focus, and opportunity? If the answer no longer makes sense, be honest with the team, understand how it got into the pipeline, and either redefine the project around a real business outcome or stop funding it.

With nearly two decades of experience in rehabilitation and founding Evolve Physical Therapy, I constantly evaluate what works and what fails in both patient recovery and business. My baseline rule for deciding whether to pivot is simple: are we actually addressing the root cause, or are we just managing the symptoms?

Early in my career, I worked in traditional clinics that showed financial progress but kept missing the mark on patient healing because of a high-volume, “churn and burn” therapy model. The definitive moment for me was seeing patients continually return with the same injuries because they were only given generic exercise sheets with minimal hands-on care.

That structural failure made the call clear to completely walk away from the traditional model and pivot to founding my own clinic in 2010. If your long-term project keeps missing its core purpose, you must stop patching up the symptoms, shut down the broken process, and rebuild around a customized, hands-on approach.

Our vendors will initially miss their timelines on a project or program. A vendor built us a custom in-house training portal for our non-clinical staff. The portal was making incremental improvements but consistently failed to meet the expectations of the facility regarding its ability to allow stable video playback as well as track users through modules.

I have one rule when it comes to projects that are behind schedule; once the vendor has missed all of the agreed-upon timelines, I am done. The moment of clarity came when the vendor asked for a third extension to address a recurring issue with the system. In a professional clinical setting, you can’t keep waiting for basic administration tools to work. We shut down the custom build and went back to using an existing training platform. Immediately after we did this, we were able to get our onboarding process back on track and ensure that our office functions remained organized and productive.

As a former police officer who now owns and runs a hands-on ADV training program with my own instructors, I’ve made these calls repeatedly when helping riders progress on heavy bikes.

My rule is simple: if a rider is showing forward movement but still needs speed or momentum to stay upright through the same obstacles, we pivot back to fundamentals instead of pushing forward. The moment that made it clear for me was watching riders who could complete a loop but kept dropping the bike at low-speed transitions because they never mastered slipping the clutch and using the rear brake together.

That pattern told me the project (the current lesson plan) was masking the real gap rather than fixing it. We shut down the advanced drills, reset to stationary balance work, and only reopened the trail once control came without extra throttle.

A long running project should earn scale before it earns more time. The rule I use is this: if the project cannot handle a modest increase in volume, stakeholders, or operational scrutiny without performance slipping, then the progress is too fragile to trust. In white label and partnership heavy environments, durability matters more than isolated wins because delivery pressure always rises once confidence returns.

I have seen projects survive too long because the team proved they could fix problems manually. That is not readiness; that is resilience being misread as viability. The call becomes clear when the process works only under ideal attention. If stronger governance, clearer ownership, and better sequencing still do not reduce fragility, I would rather stop early than scale a weakness into a permanent liability.

I pay attention to where a project’s misses are landing each cycle. When the misses show up in new places every round, the project is learning. Each iteration is pulling new information out of the problem, and the shape of what we’re solving is getting clearer even when the results aren’t where I want them. I’ll fund another round in that situation.

When my team delivers solid work and the shortfall looks identical to last quarter’s shortfall, I read that as finding the limit of the current setup. At that point, I ask a narrower question: whether there’s an adjacent version of this project that attacks the problem from a completely different angle.

If I can describe that version in concrete terms within a week, we pivot. If I can’t, we shut it down and redirect the resources.

When a long-running project shows progress but keeps missing the mark, I check whether it has a single owner, a tight brief, clear acceptance criteria with a ship date, and a funded path to finish. My decision rule is simple: if it does not meet those conditions, we pause or cancel rather than keep burning resources. We enforce that rule in a short weekly review in our project-management system so decisions are timely and visible. That structure made the call clear for me and shifted teams back to finishing work instead of just starting it.

Here’s what I learned about SaaS features in MemberzPlus: decide on your numbers from the start and don’t get attached. We watched one module’s revenue retention dip under 80% for two straight quarters while support requests exploded. We killed it. Holding on was just draining our time and money away from the parts of the platform that actually worked. Now, I always define the exit metrics early and let the data, not my gut, tell me when to pull the plug.

I decide whether to pivot or stop based on one simple rule: if average project turnaround time keeps creeping up despite clear fixes, the project is not just struggling, it is structurally stuck. Turnaround time cuts through opinions because it shows whether we are actually delivering at the pace clients expect. When that metric rises, it usually points to feedback loops, poor scoping, or the wrong resourcing, and we investigate fast. If we tighten the brief and adjust workloads and the timeline still does not improve, that is the moment the call becomes clear. At that point, I will either reset the scope hard or step away from that type of work rather than let it drain the team and the client relationship.

At Tall Trees Talent, long-running searches that drift off target are pretty common, especially in the energy sector where requirements evolve as projects evolve. The challenge isn’t whether you’re making progress—you usually are—it’s whether that progress is actually converging on what the client needs.

Over time, I’ve learned that most of these situations don’t fail because of effort. They fail because the definition of success shifts.

Early in my career, I probably held on too long in the wrong way. I’d assume more time or more candidates would eventually close the gap. Sometimes that works, but often it just extends frustration on both sides.

The decision point I rely on now is simple: I ask whether the target itself is still stable. If the feedback we’re getting is consistent and specific—even if we haven’t landed it yet—I stay in the search and refine the approach. That’s a pivot situation. We adjust sourcing strategy, tighten calibration, and keep going.

But if the feedback starts changing in fundamental ways—different priorities, shifting expectations, moving goalposts—that’s when I step back and reset the conversation with the client. Not to shut it down, but to re-anchor what we’re actually trying to solve.

One example stands out. We had a senior operational search where early progress looked strong, but every finalist was being rejected for slightly different reasons. After a few cycles, it became clear the role itself was still being defined internally. Instead of walking away, we paused submissions and re-engaged the stakeholders to rebuild alignment on what success in the role actually meant. Once that clarity was restored, the search moved quickly.

That’s the key distinction for me. I don’t believe in giving up on a search just because it’s difficult. But I do believe in recognizing when you’re optimizing execution against an unstable target.

So the rule is this: if the problem is fit, we persist and refine. If the problem is definition, we stop and realign. Either way, the goal isn’t to quit—it’s to make sure everyone is actually aiming at the same outcome before more time is spent chasing it.

When a long-running project shows progress but still misses the mark, I decide based on whether it is becoming something we will have to keep alive for years. The moment it becomes clear is when the work shifts from building features to carrying obligations like security patches, documentation, and ongoing changes, without a realistic plan to support that over time. At that point, I use a simple rule: buy off the shelf if the problem is common, and only keep building if the workflow is truly unique to your business. If it is not unique, continuing to push forward usually turns a “cheap on day one” project into the most expensive one by year three. That is when I pivot to an existing solution or shut the internal build down, rather than letting it quietly become mission critical by default.