Great Artists Ship

Right after the build

Putting a product on the market is often described as “launch.”

That word is convenient. It compresses a long sequence of decisions into a single date on a calendar. It makes the work sound finished.

It isn’t.

Tony Fadell is very explicit about this in Build⁽¹⁾: building a product and bringing it into the world are different jobs. Many products struggle not because they were badly built, but because no one took responsibility for how they were introduced, explained, and supported once they existed. He even argues that you should start by writing the press release first, not as marketing fluff, but as a forcing function. If you can’t explain the product clearly, you don’t understand it yet.

This applies to any kind of product. Physical goods. Services. B2B offerings. Internal tools. Software. The medium may change, but the responsibility remains.

From a product manager’s point of view, putting a product on the market means doing several specific things, in a sensible order.

First, test before you announce.

Before anything is public, the product needs exposure outside the core team, but under control. That might be an internal beta, a pilot with selected customers, or a limited market test. It’s the intent that matters, not the label. At this stage, you’re not testing demand. You’re testing assumptions. Does the product work without explanation? Do people use it the way you expected? Where do they hesitate, fail, or ask for help? If you skip this step, the public launch becomes the test environment, and learning gets expensive.

Second, align internally before you speak externally.

Before customers hear about the product, the people who will sell it, support it, explain it, and defend it need a shared understanding of what the product is for, what it is explicitly not for, and what success looks like in the first months. Sales needs to know when not to sell it. Support needs to know what it does not do. Leadership needs to agree on the initial promise. Internal misalignment shows up immediately after launch as mixed messages, overpromising, and reactive damage control.

Then, choose how the product enters the world.

Not every product should be launched the same way. In practice, you’re usually choosing between three patterns, whether you name them or not.

A silent launch means the product is live but barely announced. No campaign, no noise. You let real usage accumulate quietly while you watch behavior and fix rough edges. This works well when you’re still learning, or when the cost of being wrong is high.

A gradual rollout means controlled exposure. You start with a limited audience, expand deliberately, and adjust as you go. This is useful when the product touches operations, support, or pricing in ways that need tuning under real conditions.

A big bang launch is full visibility from day one. Press, marketing, sales push, everything at once. This only makes sense when the promise is clear, the organization is ready, and you’re confident you can support the demand you’re about to create.

These options aren’t mutually exclusive, and none is inherently better. Products often start quietly, expand deliberately, and go loud only when the organization is ready. What matters is choosing deliberately, not going public unplanned or ending up with a big bang by default.

After that, prepare the boring but critical surfaces.

The website has to explain the product simply. Sales materials have to match the actual promise. Customer support needs answers before tickets arrive. Internal FAQs need to exist before confusion does. If these aren’t ready, people improvise explanations on the fly. Those explanations diverge. That divergence becomes the product’s reputation. This is where Fadell’s advice about writing the press release first becomes practical: it exposes vagueness and contradictions early.

Finally, measure. Behavior, not just sentiment.

After launch, measurement is not about reporting success. It’s about learning. Performance, adoption, retention, and usage patterns matter. But so do quieter signals: which features are ignored, where people drop off, where support load spikes, where workarounds appear. Compliments and complaints are easy signals. Behavior is harder, and far more reliable. If you don’t decide in advance what learning success looks like, you’ll default to shipping more features as a response to uncertainty.

Putting a product on the market is not a celebration. It’s a transfer of responsibility from the team that built it to the reality it has to survive in.

When you test early, align internally, choose how the product shows up, prepare the basics, and measure what people actually do, you’re not just putting something on the market.

You’re giving your product a real chance to succeed and yourself a clear path to learn, improve, and make the next decision better than the last.

---

Further reading

(1) Tony Fadell — Build: An Unorthodox Guide to Making Things Worth Making.
A book I learned a lot from, written from real experience, with clear thinking on launches and ownership beyond the build.