BONUS - Jason Fried On To-Do Notifications

Sean introduces the episode as a special bonus, sharing a discussion with Jason Fried about a specific feature in Basecamp—the ability to explicitly specify who should be notified when a to-do is completed. The discussion sets the stage for exploring the rationale behind the feature's design and the internal debates about making it clearer and more explicit.

The core part of the discussion revolves around a new feature allowing users to assign notifications to specific people when a to-do is completed. The team reflects on whether to ship this feature as-is or improve its clarity, considering existing implicit rules about notifications. They debate how systems often include invisible rules that get accepted because users adapt to them, but these can cause confusion. Ultimately, they decide to ship the feature but acknowledge its imperfections, viewing it as a step forward to learn and improve.

Sean and Jason discuss the difficulty of modifying established features versus creating new ones. They highlight how users develop workarounds for unclear features, making changes potentially disruptive. There’s an emphasis on thoughtfully managing change, especially with a large user base, and understanding that additive changes are easier to adopt than modifications to existing workflows. The discussion underscores the importance of recognizing the psychological resistance to change.

The conversation explores the concept of 'rolling back' versus 'rolling forward' with product releases. Jeff's idea of 'rolling forward'—leaving a new feature in place despite initial criticism—encourages progression and iteration instead of retreating to previous versions. They give an example of a UI change in Basecamp and explain the benefits of staying committed to improvements, even if they generate short-term discomfort or feedback, aiming for long-term betterment.

Sean explains how final decisions are delegated to Scott, the project lead, emphasizing the importance of trust and clear ownership. He discusses the idea of 'points' as a way to clarify who has the final say on product features. This approach fosters autonomy and reduces the need for constant managerial input, allowing teams to move quickly and confidently.

The episode concludes with reflections on gathering feedback after a feature launch, the transparency of notifications, and how simple changes can have wider implications. The team considers delaying the launch to refine the feature further or moving forward quickly to gauge real-world use and reactions, underlining the importance of balancing uncertainty with the desire for progress.