37signals: V1 is for Us

Why your v1 should always be built for you.

Building for “everyone” often means building for no one. When Jason Fried and David Heinemeier Hansson of 37signals reflected on this, they realised how easy it is to stray into imaginary use cases. That’s where product direction gets cloudy, and you risk creating something that doesn’t truly solve anyone’s problem.

Here’s why they insist that v1 is strictly for internal needs:

☑ Clarity over “what’s next”
▪️ When solving your own problems, the roadmap is natural—you build what’s useful now, not what might be.
▪️ This approach reveals real needs instead of stacking features to please hypothetical customers.

☑ Avoid “v1 that sucks” syndrome
▪️ Many companies launch mediocre v1s, relying on future versions to “get it right.” Instead, 37signals focuses on making v1 excellent for them, so they can launch strong from the start.
▪️ This also drives motivation, as the team gets immediate value from the product.

☑ Stay true to the vision—don’t add just to add
▪️ HEY launched without email signatures (a big Gmail feature). Why? It wasn’t essential for Jason or David. They focused on solving their email issues, like creating a cleaner inbox experience.
▪️ Result? They focused on real pain points, making HEY a fresh alternative rather than just a Gmail replica.

So, after launch, what’s next? Instead of caving to immediate feedback, they let the product breathe. New users might react with, “I need a delete button!”—but the problem isn’t a missing button. It’s helping users understand that HEY handles organisation differently. And yes, they listen to user needs, but the solution? Often something users haven’t imagined.

When in doubt, build for you.

It can't be built for an imaginary reason. It has to be built for a real reason

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

The problem with these imaginary use cases is that it becomes very difficult to gauge the quality of your implementation when you're holding it up against the fantasy

When you're solving your own problems, you're essentially giving yourself the roadmap to completion that just goes straight through, 'What do I need? What is the next thing that I need?' without having to imagine it all upfront

By the time the new thing is substantially better, we'll know it's time to release

There's a crossover point where you're like, 'Oh, this is better than what we have,' and what's actually exciting about this is... I feel like I have the freedom to actually pay more attention to what we really, really need

We knew from the outset there was no way we were going to match every feature that exists in Gmail, but we were going to match the ones we needed

V1 is for you... it's giving yourself permission to launch with way less than a hundred percent of everything that you imagine other people will want

If you're just matching everyone with their existing solutions... there's no reason for them to pick you. You have to be novel, you have to be above, you have to be different, and that's the place to start

The easy thing is to go like, 'Oh, I got it wrong. We better change that really quick.' We're getting all this feedback and this is why you have to lean back and go, 'Do you know what? I should have some confidence that we are good software designers.'

Sometimes even just the mediocre conception of the problem paired with excellent execution can actually be competitive

The moment we take something like Writebook and we put it back on the shelf and we don't really use it, that's when software goes to shit

Changing habits, changing expectations. Humans just don't like that at all

What I like is I like the challenge of figuring out an alternate solution to a problem that I understand is a problem for some people, but not just giving into it and doing it the other way

The really creative stuff comes from... listening to requests, trying to dig in, find the underlying problem, and then come up with something novel in response

You're never going to be able to push through with real breakthroughs unless you have some of that confidence because everyone casts everything that they use in the context of something similar that they were already doing

This is the old asking for faster horse, getting a car issue, right? You're not going to hear the novel product design in most cases from people directly. You have to come up with that