Building products people keep
Launching is the easy part. What we have learned from running our own apps about the months after launch day.
We run our own products, from a Mac utility to a clinic platform, and the most useful lessons have come after launch day, not before it. Launch gets attention. What decides whether a product lasts is whether the people who try it in the first week are still there in the tenth.
The first week is the product
Whatever a new user does in their first few sessions becomes their idea of what the product is. If the first session ends with something useful done, the product is useful. If it ends with a settings page, the product is complicated. We design that first path before almost anything else, and we revisit it more often than any other screen.
A loop, not a roadmap
Exhibit 1
The loop that keeps a product alive
Our best roadmap input is the support inbox. When the same question arrives three times, the product is unclear, and the fix belongs in the product rather than in a help article. When we ship that fix, we reply to the people who asked. It takes minutes, and it turns a complaint into the reason someone stays.
“The support inbox is the most honest research tool a product team has.”
Release small, release often
Big releases are exciting to plan and risky to ship. Small, regular ones keep the product moving, keep each change easy to undo, and give users a steady sense that someone is looking after the thing they rely on. Trust in software is mostly the feeling that it is still being cared for.
The same habits apply to the products we build for clients. Launch is the middle of the work, not the end of it.
Written by the team at Bytelights, a product and AI studio in India.