Skip to main content
The Rework Podcast

Seven Shipping Principles

22 min episode · 2 min read
·

Episode

22 min

Read time

2 min

Topics

Philosophy & Wisdom

AI-Generated Summary

Key Takeaways

  • Quality threshold: Ship only good work, not minimally viable products. This standard gives teams permission to stop projects that aren't ready, even after weeks of development. Aim for 80-95% shipping rate, not 100%, to maintain proper standards.
  • Confidence calibration: Apply testing rigor proportionate to criticality. Billing systems require extensive testing and reviews, while minor features need less ceremony. Avoid shooting sparrows with cannons by using one-size-fits-all protocols that waste time on trivial features or underprotect critical ones.
  • Post-launch ownership: Developers and designers must monitor error trackers and handle support issues after shipping their work. This feedback loop prevents isolation from reality and calibrates future confidence levels. The two-week cooldown period provides time for cleanup without jumping to new projects.
  • Premise over implementation: When development becomes hard, question the underlying problem rather than perfecting a flawed solution. Step back from specific solutions like keyboard shortcuts to identify the core need, which may reveal simpler approaches using existing capabilities that better serve user goals.

What It Covers

37signals cofounders Jason Fried and David Heinemeier Hansson explain their seven shipping principles for building software at a sustainable pace, focusing on quality standards, confidence calibration, and ownership accountability.

Key Questions Answered

  • Quality threshold: Ship only good work, not minimally viable products. This standard gives teams permission to stop projects that aren't ready, even after weeks of development. Aim for 80-95% shipping rate, not 100%, to maintain proper standards.
  • Confidence calibration: Apply testing rigor proportionate to criticality. Billing systems require extensive testing and reviews, while minor features need less ceremony. Avoid shooting sparrows with cannons by using one-size-fits-all protocols that waste time on trivial features or underprotect critical ones.
  • Post-launch ownership: Developers and designers must monitor error trackers and handle support issues after shipping their work. This feedback loop prevents isolation from reality and calibrates future confidence levels. The two-week cooldown period provides time for cleanup without jumping to new projects.
  • Premise over implementation: When development becomes hard, question the underlying problem rather than perfecting a flawed solution. Step back from specific solutions like keyboard shortcuts to identify the core need, which may reveal simpler approaches using existing capabilities that better serve user goals.

Notable Moment

David argues shipping rates approaching 100% indicate standards are too low, not excellence in execution. Teams should expect some projects to fail the quality bar, creating healthy tension between ambition and realistic assessment of readiness.

Know someone who'd find this useful?

You just read a 3-minute summary of a 19-minute episode.

Get The Rework Podcast summarized like this every Monday — plus up to 2 more podcasts, free.

Pick Your Podcasts — Free

Keep Reading

More from The Rework Podcast

We summarize every new episode. Want them in your inbox?

Similar Episodes

Related episodes from other podcasts

Explore Related Topics

This podcast is featured in Best Business Podcasts (2026) — ranked and reviewed with AI summaries.

You're clearly into The Rework Podcast.

Every Monday, we deliver AI summaries of the latest episodes from The Rework Podcast and 192+ other podcasts. Free for up to 3 shows.

Start My Monday Digest

No credit card · Unsubscribe anytime