The Setup
In 2012, Basecamp (then still called 37signals) published a post-mortem on a feature that had shipped on time, under budget, and to near-zero adoption. The team had executed well by every internal metric. Tickets closed. Code merged. QA passed. The feature was done.
Except it wasn’t. Not really.
The people who had originally requested the feature, a set of long-term customers who had been vocal about the problem it was meant to solve, never knew it shipped. They hadn’t been looped back in. Some had already built workarounds. Others had quietly churned. The loop that started with their complaint was never closed.
This wasn’t a communication failure in the dramatic sense. Nobody forgot to send an email out of negligence. The team had simply confused completing a task with completing a conversation. Those are not the same thing, and confusing them is one of the most consistent productivity mistakes knowledge workers make.
What Happened
Here is how the situation unfolded in practice. A handful of customers had reported friction with how Basecamp handled recurring project templates. The feedback was logged, triaged, prioritized, and eventually built. The product team shipped a solution.
What they did not do was trace the original thread back to its source. The customers who had surfaced the problem were not notified. There was no update in the original support thread. There was no changelog entry written in plain language for that specific audience. The communication loop that had opened with a customer complaint closed inside the company’s internal tracker, visible only to people who already knew the feature existed.
Customers are not watching your Jira board. They raised a concern, got an acknowledgment, and then heard nothing. From their perspective, nothing had changed. So they adapted accordingly.
37signals eventually built explicit practices around this. Jason Fried and David Heinemeier Hansson have written and spoken at length about the idea that work has a social dimension that can’t be tracked in tickets. “Basecamp” as a product is, in many ways, a direct response to the failure mode of siloed task completion. The company’s entire methodology, documented in books like Shape Up, treats communication as a first-class deliverable, not an afterthought.
But the lesson took time to crystallize, and the 2012 feature story is useful precisely because it happened before the methodology was fully formed. It shows the failure mode in its natural state.
Why It Matters
Finishing a task gives you a clean signal. The checkbox turns green. The ticket moves to Done. Your brain gets a small reward. This is genuinely useful, and you should not feel bad about it.
The problem is that this signal is incomplete. A task exists inside a larger context, which is usually a loop: someone noticed a gap, surfaced it, work was initiated, and now someone is waiting, consciously or not, for resolution. Finishing the task closes the internal loop. Closing the actual loop means returning to the origin point and completing the circuit.
Psychologists call the discomfort of an unresolved loop the Zeigarnik effect, the cognitive weight your brain assigns to unfinished business. What’s less discussed is the inverse problem: tasks that feel finished but have only closed internally. You’ve released the cognitive weight, but the other person in the conversation is still carrying it. From their vantage point, you’re still mid-task.
This creates a specific kind of organizational drag. Why your team’s definition of done is broken gets at part of this problem: when “done” is defined by internal state rather than external impact, you’re measuring the wrong thing. A feature that ships but isn’t adopted didn’t finish. It stalled.
What We Can Learn
The Basecamp case points toward a few concrete habits worth building into how you and your team work.
Start every task by identifying who opened the loop. Before you mark something done, ask: who surfaced this? Where did the original ask come from? It might be a customer ticket, a Slack message from a colleague, a comment in a doc, or a question raised in a meeting. Write it down at the start of the task, not the end, because by the end you will have forgotten.
Treat loop closure as a deliverable, not a courtesy. This is a mindset shift, not a soft skill. When you plan a task, plan the closing communication as part of the work. It is not extra. It is not optional. If a customer complaint triggered the work, notifying that customer when the work ships is part of the job. Block time for it. Put it in the ticket.
Audit your recent completions. Look back at the last ten things you marked done. For each one, ask: did the person or group who originated this know it was resolved? You will find gaps. That’s expected. The exercise is not about guilt, it’s about building a habit of tracing work back to its source.
Use the original channel. If someone raised an issue in email, close the loop in email, not in your project management tool where they don’t have access. If they raised it in a Slack thread, reply to that thread. Meeting people where the conversation started is not inefficiency. It’s how you complete communication rather than just completing work.
Distinguish between loop types. Some loops are tight, a colleague asked you a question and needs an answer. Some are loose, a feature request that came from a quarterly survey. The closing communication looks different in each case. Tight loops need explicit replies. Loose loops often need changelog entries, release notes written for humans, or direct outreach to the original requesters. Know which kind you’re closing.
One of the counterintuitive things about this practice is that it makes you faster over time, not slower. When people trust that you will close loops, they stop following up. You eliminate an entire category of “just checking in” messages that are, at their core, people reopening loops you left open. Every unacknowledged task completion is an invitation for a follow-up you’ll have to handle anyway.
The Basecamp story is a clean illustration of a very common problem: a team that measured its own success by the wrong signal. They weren’t lazy or careless. They were optimizing for task completion in a situation that required conversation completion. The fix isn’t to work harder. It’s to define done more honestly.
You finish tasks. You close loops. Only one of those moves the work forward.
