Launch6 min read

The first version is
a conversation.

Ship the smallest thing that can teach you something true, then let the next version answer what you learned.

Founders often treat launch as a ceremony. The product is polished, the announcement is prepared, and the team waits for the market to deliver a verdict. But a first release is not a verdict. It is an instrument for asking a better question.

Small is not the same as incomplete

A small first version has a narrow promise and a complete loop. It lets one kind of user do one meaningful thing from beginning to end. It can be simple, manual behind the scenes, or intentionally limited. What matters is that the user can experience the value and the team can observe the result.

An incomplete version has missing decisions. It pushes complexity onto the user and calls the confusion feedback. Scope is a product decision. Neglect is not.

The first release should be small enough to change and real enough to teach.

Make the conversation easy

Paul Graham’s advice to early founders is direct: recruit users manually, make them unusually happy, and learn from the work. That is not a temporary substitute for growth. It is how the product discovers what it is.

  • Put the first version in the hands of a specific group, not an abstract audience.
  • Watch what people do before asking what they think.
  • Respond quickly enough that users can see their feedback become product behavior.
  • Track retention and repeated use before celebrating reach.

Design the next question

Every release should have a learning objective. Are people returning? Can they complete the core action without help? Does the outcome solve the problem well enough to earn another attempt?

Write the question before the release. Define what evidence would change your plan. Otherwise a launch becomes a referendum on your identity, and no amount of data will feel clear.

Launch is a practice

The best teams make shipping ordinary. They create a rhythm of small releases, direct conversations, review, and correction. Over time, the product becomes less like a bet and more like a shared understanding between the team and the people it serves.

Research notes

Paul Graham, “Do Things that Don't Scale”
James Shore and Diana Larsen, “The Agile Fluency Model”

Back to journalRead the other notes