Launching and collecting feedback

Many founders picture a launch as a big event: press, a party, thousands of users in one day. In reality your first launch should be much more modest. The goal is not noise; it is to start learning from real users.

Give the product first to the people you interviewed. They know the problem, they have talked to you, and they are often waiting for the result. Ten or twenty active users give you more useful information than thousands of random visitors. You can make a big announcement once the product really works.

Sit side by side with your first customers. Go to the shop, install the product on their phone, enter the first data together. This does not scale, but it gives you two big benefits: the customer actually starts using the product, and you see with your own eyes where they struggle. Many problems surface in meetings like these: an unclear button, too many steps, information missing where it is needed.

People cannot always describe accurately what they do. Watch what they do. Set up basic analytics: who signed in when, whether they completed the main job, at which step they stopped. Look at this data for a few minutes every day. You are looking for answers to two questions:

Open a separate Telegram group or a personal chat for your first users. Answer questions there quickly, admit mistakes and let people know when something is fixed. Every week or two, call your most active users. Message the ones who quietly stopped, too: finding out why someone stopped is often the most valuable information you can get.

Users will send you lots of requests: a new feature, a different colour, another report. If you try to do them all, the product becomes scattered and complicated. Weigh each request with three questions:

If a customer says "add an export to Excel", ask why. Perhaps they want to send a monthly report to their business partner, and a ready-made report would suit them much better.

The most effective early teams work to a simple rhythm: they change the product every week and talk to users every week. Write down briefly at the start of each week what you will do and at the end what you learned. After a few months these notes show you how far you have come.

Many teams delay launching for months because the product is "not ready yet". But a product is never completely ready. A first version will have rough edges; that is expected. Waiting until it feels polished usually means you have waited too long. Early users forgive flaws, as long as you listen to them and fix things fast.

Bugs will show up in the first weeks. Do not fear them; handle them well. Keep every bug on one list and rank them by impact: a bug that blocks the main job comes first, a small cosmetic flaw later. Thank the customer who reported it, tell them when it will be fixed, and let them know yourself once it is. Customers often remember that kind of response more than the bug itself, and it builds trust.

Make a list of your first ten users and plan when and how you will meet each of them. Write down how you will measure that the main job was done in the product. For the first two weeks, record the most important observation of each day in one sentence.