Know When to Stop: Sunsetting Goals to Protect Focus
Every resource invested in the wrong goal is a resource stolen from the right one. This guide draws on insights from experienced operators and advisors who have learned to recognize when persistence becomes waste. The eighteen strategies that follow offer practical tests to identify which efforts deserve continuation and which demand immediate shutdown.
Cut Efforts That Block Better Bets
Projects deserve patience at the start, but not protection forever. The turning point usually appears when the work begins creating friction beyond its direct cost, slower decisions, diluted focus, and less confidence in priorities. Those secondary effects are often more damaging than the underperformance itself.
A clear example came from an internal growth initiative that looked harmless in isolation but kept delaying stronger experiments. The threshold was simple, if an effort blocks two higher confidence opportunities in the same month, it loses its slot. We retired it after that happened twice. The freed capacity produced faster execution and a clearer path to revenue within the same quarter.
Apply The Advocate Standard Quickly
The most difficult leadership skill no one teaches is distinguishing between a project that requires more time and one that borrows time from something better.
Most organizations abandon projects too late, after sunk cost psychology has turned rational evaluation into emotional defense of previous decisions.
We devised a threshold mechanism known as "The Advocate Test."
Every active project requires an identified internal advocate - someone who believes in the project's strategic significance and advocates it willingly rather than being told to do so. Projects that fail to create natural advocacy within 90 days of debut are immediately reviewed, regardless of money or schedule remaining.
Our most talented employees were consistently finding reasons to work on other projects without complaining or requesting reassignment, indicating a silent vote of no confidence within the organization.
I'm not whining about the project. I am not asking for reassignment. Simply moving on, the organizational equivalent of a silent vote of no confidence.
Our decision to discontinue an 11-month product development initiative resulted in a change that generated $1.4M in revenue in just two quarters. It's important to distinguish between sunk cost and opportunity cost.
Sunk cost refers to what you've spent. The opportunity cost measures what you lose by staying.
Drop Deals That Demand Founder Attention
I killed a seven-figure revenue stream in 2019 because it was eating my team alive. We were running custom fulfillment projects for enterprise clients - great margins on paper, but every deal required 40+ hours of implementation work and constant hand-holding. The revenue looked impressive in our P&L, but when I actually tracked founder hours per dollar earned, we were making less than if I'd just taken a consulting gig.
The threshold that made it crystal clear was what I call the "Sunday night test." If thinking about a project on Sunday evening fills you with dread instead of energy, it's already dead - you just haven't admitted it yet. I was dreading client calls. My ops team was working weekends to fix one-off customizations. We had revenue but zero leverage.
Here's the specific math that forced my hand: I calculated that our custom enterprise work generated $1.2M annually but consumed 60% of my time and 40% of my team's capacity. Meanwhile, our standardized fulfillment services did $8M with maybe 20% of total capacity. The ROI gap was insane. I was choosing complexity over scale because killing revenue feels like failure.
So I gave existing enterprise clients 90 days notice and referred them to competitors. Scared the hell out of me. But within six months, we'd redeployed that capacity into our core business and grew it by $3M. The team was happier. I was sleeping better.
The telltale sign isn't just low ROI - it's when a project requires YOUR specific attention to survive. If you can't delegate it without quality collapsing, and you don't love doing it, that's your answer. Kill it fast. The opportunity cost of mediocre projects is enormous because they block you from seeing what could replace them. I've never regretted cutting something too soon, but I've definitely regretted hanging on too long.
End Anything Propped Up Manually
So I double-killed anything I've rescued in the last two weeks. Last quarter I shut down an outreach campaign that was running weekly. It had required four fixes in just nine days (three hours of my week). It's not a matter of a missed metric, it's me at 11 p.m., making the same step the script always seems to get wrong. Our instinct in this business is to give another project another sprint. But that sprint is usually me manually taking care of it. A project that runs without my involvement is healthy; a project that I'm keeping alive is on life support. I just wasn't willing to say it out loud. It wasn't about capacity, it was about being honest about who was doing the work.
—
Justin Mauldin
Founder & CEO, Salient PR
https://salientpr.com
Gate With MEDDICC And Payback Rules
When a project stops pulling its weight I use a MEDDICC-lite qualification and a simple payback rule to decide whether to pause or terminate. The primary gates are Money (budget and per-unit target), Event date (in-hands), and Design readiness; if two of those three are weak I park the project. I also require a one-line ROI showing cost per unit versus alternatives and a projected payback within one buying cycle; if that cannot be met we reposition scope or pause. Every effort is tracked in a Mutual Action Plan with an owner, dates, and approvals so weekly reviews surface risks and confirm whether the qualification or payback thresholds still hold.
Project Future Benefits Before Decision
Usually I'll try to look ahead and figure out what the project or goal will result in benefits-wise in the future. Sometimes this will help me see if the current situation is only temporary and things will likely get back on track. Other times it may help me see that investing any more time or resources into it will be a waste.
Set A Firm 90-Day Traction Window
I've had to make this call more times than I'd like to admit working at Santa Cruz Properties. When you're juggling marketing campaigns, tenant outreach, property listings, and investor relations, you can't afford to keep dead weight around.
My rule of thumb is pretty straightforward. I give any new initiative a 90-day window to show signs of life. If we're not seeing measurable traction by then, whether that's leads, engagement, or actual leases signed, it's time to have a serious conversation about pulling the plug.
The clearest example I can remember was when we launched a targeted direct mail campaign for some of our vacant commercial properties in the Rio Grande Valley area. We poured resources into designing beautiful mailers, bought a solid mailing list, and sent out three rounds over two months. The response rate was abysmal. I'm talking less than half a percent when we normally see two to three percent on our residential campaigns.
The telltale sign for me wasn't just the low numbers though. It was the feeling I got when I'd look at the data every Monday morning and realize I was dreading reporting on it. When you start avoiding looking at performance metrics because you already know they're going to be disappointing, that's your gut telling you something needs to change.
We killed that campaign and reallocated the budget to digital ads targeting small business owners looking for warehouse space. That shift generated three new leases within the first month.
Sometimes the hardest part isn't recognizing that something isn't working. It's admitting you were wrong about it in the first place. But I've learned that every dollar and hour we spend on an underperforming project is a dollar and hour we're not investing in something that could actually move the needle for our properties and our tenants.
You have to be ruthless with your time and resources in this business. There's always something more productive waiting for your attention.
Track SaaS Health And Efficiency Metrics
When a project stalls I rely on a focused set of SaaS metrics to decide whether to pause or terminate it. I watch for falling MRR, rising churn, or Net Dollar Retention dropping below 100% as immediate warning signs. I also use efficiency benchmarks such as LTV/CAC—where a ratio under 1 is unsustainable and a ratio above 3 is healthy—and the Magic Number and Rule of 40 to assess spend efficiency and balance of growth versus profitability. If several of these metrics deteriorate together and fixing them requires disproportionate investment, I pause or terminate the project to free capacity for higher-return work.
Ask The Start-Today Question Ruthlessly
I've had to make this call more times than I'd like to admit at Sunny Glen. A few years back, we launched a mentoring program pairing our older youth with business owners in the community. Sounded great on paper, right? The goal was to build job skills and connections for kids aging out of care.
But six months in, the numbers told a story I didn't want to hear. Only three of our twelve kids were showing up consistently. The mentors were frustrated with the no-shows. My staff was spending hours coordinating something that wasn't landing.
My threshold question became pretty simple: "If we weren't already doing this, would we start it today?" When the answer is no, that's your sign.
The telltale sign for me is when I hear myself or my team making excuses based on sunk cost. "But we've already invested so much time" or "The donor who funded this expects it to continue." Those aren't reasons to keep going. They're reasons you're afraid to stop.
With that mentoring program, I had to get honest. The kids who needed it most weren't engaging. The format didn't fit their lives. We paused it, reassessed, and redirected that staff capacity into a partnership with a local trade school. That program now has a waitlist.
Here's what I've learned: killing something isn't failure. It's making room for what actually works. At Sunny Glen, our mission isn't to run programs. It's to serve kids. When a program serves the program more than the kids, it's time.
I now do quarterly reviews of everything we're running. I look at participation data, staff energy, and outcomes. If something isn't meeting at least 70% of its targets after a reasonable ramp-up period, we either pivot significantly or let it go.
The hardest part isn't making the decision. It's being willing to see the truth when you want something to work.
Tie Choices To Delivered Outcomes
When a project stops pulling its weight, I first ask whether the work that actually matters is being delivered against clear ownership and expectations. I rely on regular progress check-ins and the meeting action items we generate to see whether responsibilities are being met and blockers are being removed. If these check-ins show no measurable forward movement and agreed action items remain incomplete despite intervention, I pause or wind down the effort to free capacity for higher-return work. That keeps the decision tied to observable outcomes rather than visibility or activity.
Model Drivers And Act On Volatility
I base the decision on objective data and whether that data shows persistent cost drivers or volatility that cannot be managed within the current scope. In one engagement steady renewal increases led us to analyze HRIS, enrollment, and claims and we found high dependent participation, pharmacy spend concentration, and a very rich plan design with a low deductible. Those measurable signs and ongoing claims volatility made it clear the effort was not pulling its weight as structured. We modeled actual claims performance and used the model results plus a commitment to quarterly claims reviews to decide whether to adjust the approach or free capacity for higher-return work.
Align Work To The Present Bottleneck
My filter is whether a project still matches the current needs of the business. A project can be well built and still be wrong for this moment. We review each effort against the bottleneck we need to fix now not the one before. This helps us avoid time on work that solved an old problem.
I made call when a project kept asking for more work though the main problem had changed. We were not limited by awareness we were limited by conversion and focus. Our rule was simple if next work improved a metric and did not fix the main constraint we stopped. This freed our team to focus on a effort that gave gains faster with less effort.
Trigger Shutdowns With Content-Effort Ratio
Content Hours Per Thousand Pageviews Triggered Site Shutdowns
I track one number for every publication in our network: content hours per thousand pageviews. When that ratio climbs above our threshold for three consecutive months, the publication is a candidate for shutdown.
We learned this the hard way in 2021. We were running a DeFi-focused publication that had strong early traffic but kept requiring more content to maintain it. Our writer was spending 18 hours a week on it. Traffic was stuck at 45,000 monthly pageviews. That works out to about 0.4 content hours per thousand pageviews. Meanwhile, our general crypto publication was getting 180,000 pageviews with 12 hours a week of content work. That's 0.067 hours per thousand.
The DeFi site was consuming 2.8 times the content investment for traffic that wasn't growing. We kept it running for two extra months because the content quality was high and the writer liked the niche. But high quality without efficiency is just expensive.
I pulled the numbers in a spreadsheet. Calculated content hours divided by monthly pageviews for each site. Sorted by ratio. The three worst performers were all sub-niches that had plateaued. They were taking 35% of our content team's capacity but delivering 11% of our total traffic.
We shut down two of them within 30 days. Redirected the domains to our larger sites in the same verticals. Reallocated the writers to publications where the same hours would reach six times the audience. Traffic on the main sites climbed 22% in the next quarter because we could finally publish daily instead of three times a week.
The threshold I use now is simple. If a publication stays above 0.3 content hours per thousand pageviews for 90 days and shows no growth trajectory, we either find a way to automate more of it or we kill it. Capacity is finite. Sentiment about a project doesn't pay for itself.
Watch Flow Time And Task Queues
I decide to pause or kill a project by watching flow efficiency, specifically the flow time from briefing to delivery. When flow times lengthen consistently and work starts queuing or bouncing between people instead of progressing, that tells me value is slipping. Persistent rework within those flows and a growing gap between reported utilization and actual delivery prompt me to pause and reallocate capacity. Pausing lets us remove blockers, reassess scope, and prioritize higher-return work before making a final kill decision.
Trust Emotional Drag And Clarity Tests
One sign I trust is emotional drag. In business good initiatives create pressure but also clarity. Bad ones create fatigue without real progress. When a project makes managers reactive cautious or dependent on constant interpretation it takes more than it gives.
The clearest test I use is simple. If frontline leaders cannot explain in one sentence how a project reduces risk or improves performance I consider it unclear. I once saw an initiative that looked strategic from the top but felt distant in daily work so we stopped it. We shifted effort to something more direct and adoption improved because the value was visible in daily work over time quickly.
Demand Clear Behavior Change Per Session
I kill projects when they stop changing user behavior. That sounds obvious, but I learned it the hard way. In our world, the most common photo is bathroom ceiling mildew. The real issue usually is poor ventilation, not mystery mold. So we built a feature that tried to classify the spot more precisely from a photo. People liked the output, but they still asked the same next question, "What do I do now?" The signal was clear. Classification alone wasn't reducing confusion or helping people act. Once I saw that, we paused work on deeper photo labeling and shifted to action-first guidance. Things like, use a 50+ CFM exhaust fan and run it 20 minutes after a shower. Keep humidity under 60%, because mold can start growing on cool surfaces within 48 to 72 hours. That change pulled its weight. It helped users decide whether to clean, monitor, or call a pro. My threshold is simple, one behavior change within one user session. If a feature doesn't help someone make a clearer next decision, it goes on pause. Interest is not enough. Accuracy theater is not enough. A project earns resources when it shortens the path from "I see a problem" to "I know my next step." My rule, if the output is interesting but doesn't change action, kill it.
Compare Honest Trajectories Against Alternatives
I'm a clinician-founder who's had to make pause-or-kill decisions on multiple operational and clinical initiatives across the growth of Interlinked Wellness. The threshold that's worked most consistently for these decisions is what I'd call the opportunity-cost-with-honest-trajectory test.
The mechanics: for any project that's not delivering against expectations, the decision isn't whether the project is failing in absolute terms. It's whether the resources the project is consuming would produce more return if redirected to a different opportunity. The honest answer requires two pieces of information -- a realistic projection of where the current project will be in six to twelve months if continued, and a realistic estimate of what the resources would produce in an alternative use. Both projections are uncertain; both have to be made honestly rather than optimistically about either side.
The telltale signs that say it's time to consider the pause-or-kill conversation: the project's metrics have been flat or declining for the past three to four reporting cycles, the team's energy on the project has shifted from generative to maintenance-mode, the original assumptions that justified the project have been disconfirmed by subsequent data, and the project is now competing with newer opportunities for the same operational attention.
The single threshold I use: if the project's projected return over the next twelve months is less than 60-70% of what the same resources could produce in an alternative use, I pause or kill. The lower threshold accounts for the real cost of switching (the alternative use has implementation friction the existing project has already absorbed). Above that threshold, continuing is probably right even when the current project feels underwhelming.
What I avoid: killing projects in their early-friction phase before they've had time to actually compound (most projects look unimpressive before they take hold), continuing projects out of sunk-cost commitment (the resources already spent shouldn't influence the forward decision), and decisions made in single conversations under pressure (the threshold conversation needs space to be evaluated honestly).
The pattern: honest projections, explicit threshold, prompt documentation. The discipline saves resources across years that would otherwise be tied up in projects that aren't producing their share.
Enforce A Hard Second-Extension Review
The threshold I use is what I call the "second extension rule." Every project gets one schedule extension, no questions asked. Software work is genuinely unpredictable, so one slip is fine. The second time the team asks for more time, the project goes on the chopping block automatically. Not killed yet. Reviewed. The default becomes pause, and the project has to earn its way back.
That single rule cut a lot of polite drift out of Paperless Pipeline. We are bootstrapped. We have never raised outside capital. Every engineering hour is a real dollar I do not get back. 16 years of running this way teaches you fast that polite optimism is the enemy of a profitable company.
Concrete sign that the call is clear. When the team starts describing what the project will "eventually" do, in vague future tense, instead of what shipped this sprint. That language shift is the tell. A healthy project speaks in past-tense outcomes. A dying project speaks in future-tense promises.
Before/after example. We had an internal reporting feature in flight for about four months. It missed its first delivery date by three weeks, which I waved through. When the team asked for a second extension, I applied the rule. We paused, dug into the data, and found that almost no customers had asked for what we were building. Customers had asked for a closely related thing that would take a quarter of the effort. We killed the original. Shipped the smaller version in three weeks. Customers thanked us. The engineering team was relieved.
The discipline that makes this work is being willing to look stupid in public. Killing a project after four months feels bad. Letting it limp on for another six months feels worse, but it feels worse later, in private, when the bill comes due.
I will admit a limit. This rule needs a culture where saying "this isn't working" is rewarded, not punished. If your team gets graded on shipping no matter what, they will hide problems instead of surfacing them. Fix that first.
If you cannot point to a recent project you killed, you are not killing enough.
