Skip to main content
The Rework Podcast

V1 is for Us

32 min episode · 2 min read
·

Episode

32 min

Read time

2 min

Topics

Productivity, Relationships, Startups

AI-Generated Summary

Key Takeaways

  • Internal Use Cases Only: Version one must solve actual problems the company experiences daily, not hypothetical external scenarios. 37signals scrapped six months of work on Highrise CRM when they realized they were building for imagined customers instead of their own needs.
  • Quality Validation Through Dogfooding: Teams can only gauge solution quality when solving problems they personally experience. When 37signals forced technical staff to use Writebook despite missing search functionality, the internal rebellion revealed exactly what features needed development for reference materials.
  • Post-Launch Patience: Wait weeks or months after launching before acting on customer feedback. Users bring expectations from previous tools and need time to adapt. Hey email still receives archive button requests years later from users conditioned by Gmail habits.
  • Problem vs Solution Requests: Listen to underlying user problems, not their proposed solutions. When Hey users demanded delete buttons, 37signals identified the real problem as not wanting to see dealt-with emails, then created cover art feature allowing users to replace email lists with family photos.

What It Covers

37signals cofounders Jason Fried and David Heinemeier Hansson explain their principle of building version one products exclusively for internal company needs, using real problems rather than imagined customer use cases to guide development.

Key Questions Answered

  • Internal Use Cases Only: Version one must solve actual problems the company experiences daily, not hypothetical external scenarios. 37signals scrapped six months of work on Highrise CRM when they realized they were building for imagined customers instead of their own needs.
  • Quality Validation Through Dogfooding: Teams can only gauge solution quality when solving problems they personally experience. When 37signals forced technical staff to use Writebook despite missing search functionality, the internal rebellion revealed exactly what features needed development for reference materials.
  • Post-Launch Patience: Wait weeks or months after launching before acting on customer feedback. Users bring expectations from previous tools and need time to adapt. Hey email still receives archive button requests years later from users conditioned by Gmail habits.
  • Problem vs Solution Requests: Listen to underlying user problems, not their proposed solutions. When Hey users demanded delete buttons, 37signals identified the real problem as not wanting to see dealt-with emails, then created cover art feature allowing users to replace email lists with family photos.

Notable Moment

David admits sending an angry email five seconds after using a Tesla with swipe-based gear shifting, demanding the traditional stock back, only to realize weeks later the new system actually worked faster than physical levers he expected.

Know someone who'd find this useful?

Episode Transcript

Welcome to Rework, a podcast by thirty seven Signals about the better way to work and run your business. I'm your host, Kimberly Rhodes, and I'm joined as always by the cofounders of thirty seven Signals, Jason Fried and David Heinemeier Hanssen. Well, if you've listened to the podcast for any period of time, you've heard Jason and David talk about building software for us, that thirty seven signals uses all of its own products. We use Basecamp to build Basecamp and just how that is an important focus for the company. I thought we would talk more about it today. Jason, you recently explained to the company again that this is an important priority for us. Kinda tell us a little bit about that. Yeah. So we just had our meetup in Montreal, and we showed off two products that we're working on internally. These have been sort of discussed internally, but we've never showed them off as a group. So I showed them off with two of the designers, and I was I was sort of referencing use cases. Like, this could be used for this, and this could be used for that. And we even showed examples of it being used for tracking which flowers you have in your garden. Is this random? Whatever. But the thing is is and I gave the presentation, and it made the points. But I actually had this tinge of regret afterwards, which was, why am I showing things that it could do? Why do we have to imagine use cases? Whenever you do that, you gotta really check yourself pretty quickly. Why are we building this again? Because we're imagining how people might wanna use it? They might use it for that reason, but it can't be built for an imaginary reason. It has to be built for a real reason. And by the way, these these products we're building are built for a real reason, but I felt like I had to justify them in a sense or it was like a demo. So let me show you the all the things it can do. But it was a red flag, and so I posted something yesterday actually internally saying like, hey. We need to get back to remembering why we're building these things and specifically why we're building version one. And version one is for us. Other people hopefully will use it, will like it, will have the same needs that we have, will want their same product for the reasons we want it, but it has to be for us, it has to be tied to our use cases. And in fact, we should tie even a tighter knot and not have to imagine any external use cases. That's not to say that it can't be used for other things. For example, when we built Basecamp, version one of Basecamp was entirely 100% our use cases. And it turns out a lot of other companies have very …

Get the full transcript (6,761 words) + summary by email — free

One-time email with the complete transcript and AI summary of this episode. No account needed.

One email, no spam. We’ll also show you what SignalCast does.

Browse all The Rework Podcast transcripts →

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

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

Pick Your Podcasts — Free

Keep Reading

Books, tools, and gear mentioned in this episode

SignalCast may earn commission on purchases via these links. As an Amazon Associate, SignalCast earns from qualifying purchases.

Gear

  • by Tesla

    David admits sending an angry email five seconds after using a Tesla with swipe-based gear shifting, demanding the traditional stock back, only to realize weeks later the new system actually worked faster than physical levers he expected.

Products

  • by 37signals

    When 37signals forced technical staff to use Writebook despite missing search functionality, the internal rebellion revealed exactly what features needed development for reference materials.
  • by 37signals

    37signals scrapped six months of work on Highrise CRM when they realized they were building for imagined customers instead of their own needs.
  • by 37signals

    Hey email still receives archive button requests years later from users conditioned by Gmail habits. When Hey users demanded delete buttons, 37signals identified the real problem as not wanting to see dealt-with emails, then created cover art feature allowing users to replace email lists with family photos.

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.

Read this week's Startups & Product Podcast Insights — cross-podcast analysis updated weekly.

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 one show.

Start My Monday Digest

No credit card · Unsubscribe anytime