When is the right time to promote your product when you are a first-time founder?
Yesterday, you contributed a lot to my discussion about not sounding too salesy.
But that's not the only problem the early founders have.
They usually do not know when to start promoting, or simply do not have the courage to start.
↩️ In the past:
I used to struggle with sharing something before it was finished.
I waited until everything was done before announcing that I had built something.
Because I kept the problem to myself instead of talking about it, I couldn't validate whether it was worth building or improving the idea through feedback.
I spent a lot of time on it, and it failed.
⏺️ Now:
I have built a personal brand on 3+ platforms (Product Hunt, LinkedIn, X, Substack, YT).
Community is more likely to answer my curious questions when I am building my own tool – early feedback.
I am in the process of building and already talking about it (gathering email addresses for waitlist, #buildinpublic on X, newsletter edition, mentioned it on LinkedIn, PH discussions, changing links on socials).
I am planning to interview selected LinkedIn users who will test my product and give me suggestions.
Basically, I started with the promotion before the product was built, because I needed to have the idea validated and keep momentum while building it.
I do not know whether this way is good, because the product can flop too, or be copied.
When is the right time to promote a product when you are a beginner in launching something?

Replies
MESUT's framing is the one I keep coming back to — it's not timing, it's silence. The harder version for technical founders is when the thing you're building is hard to describe before it exists. "voice biomarker app for nervous system regulation" doesn't mean anything to most people until they've experienced it. So the promotable thing early on isn't the product — it's the problem and the question. Started talking about why nervous system data matters months before I had anything to show. That's what attracted the first real conversations. Gal's point about pivot cost is real though — there's a version of early promotion where you've built an audience around a specific promise and pivoting breaks trust. The way I think about it: promote the problem domain, not the solution. That gives you signal without locking you in.
minimalist phone: reduce your screentime
@sabber_ahamed Problem first – always sells :)
@busmark_w_nika totally agree — that's the frame I've been leaning into too. curious what you think is the right cadence for re-stating the problem once you start getting early users, does it shift?
minimalist phone: reduce your screentime
@sabber_ahamed of course, when I have users I am more motivated to continue on :D
We promoted FounderFlow before it felt ready too — mostly to find out if the problem was real for anyone besides me. Rule of thumb that worked for me: promote as soon as you can describe the problem clearly, even if the solution's still ugly.
minimalist phone: reduce your screentime
@stacywycof83995 Did it work?
@busmark_w_nika It did, slowly — the posts about the problem got way more replies than anything about the product itself, and a few of our earliest beta users came straight from people who'd commented on those. Didn't blow up overnight, but it meant we weren't building in a vacuum.
For me it ended up being the opposite of what I originally planned — I built most of Naxely quietly first, then started talking about it right around when I had something people could actually try, not before.
In hindsight I think I left feedback on the table by not talking earlier, same as what you're describing. But there's a real tradeoff on the other side too: if you promote before you have anything working, you're asking people to imagine a product instead of react to one, and the feedback you get is a lot vaguer — "sounds interesting" instead of "this specific thing is confusing."
What's worked better once I did start talking about it: sharing real, specific problems I was solving (a bug I fixed, a feature that came from an actual complaint) rather than "here's my idea, what do you think." That gets sharper responses than pre-launch validation posts usually do, at least in my experience.
I don't think there's one right answer, but if I were starting over, I'd aim for "as early as you have something tiny and real to react to" rather than fully polished, and rather than nothing at all. Talking about a raw idea with no artifact is where I'd be most careful — that's where you get politeness instead of useful signal.
minimalist phone: reduce your screentime
@deepanshu_garg9 That's true. Since my product is not ready, people only talk about how brilliant the idea is. Maybe when I launch it, and others will test it, they will hate it :D hahaha
The doer versus yapper worry has a clean fix: you are not promising anything if you only ever talk about the problem and the question. A promise is a dated claim about a feature. A problem is just an observation about the world, and you cannot let anyone down by describing something that is already true. That is the version of early promotion that carries no trust risk, so the faux pas fear mostly goes away.
On being copied, the thing worth protecting is not the idea, it is the sequence of decisions and why you made them. Anyone can see your v1. Nobody can see the twenty things you tried that did not work, and that is the expensive part to copy.
On the last worry, people saying good idea but never using it, they are right to be discounted. As a data person I trust one behaviour over fifty compliments. A reply is talk. Someone giving you their email, opening the thing twice, or asking when they can pay is signal. So my honest answer to when: start promoting the day you can state the problem in one sentence, and start selling the day a stranger takes a small action without being asked. The first is safe immediately. The second is how you find out it is real.
minimalist phone: reduce your screentime
@oshylabs The thing with the copying – of course, they cannot see 20 times before that one successful attempt, but they care only about that successful one which is the easiest copied because mistakes were done only by me and the could skip those mistakes just by directly copying me :D
@busmark_w_nika Fair, they can skip the mistakes. But they copy the what, not the why, and that is where it breaks. You know which twenty things failed and the reasoning behind the one that worked, so when the market shifts you adjust. The copier holds a frozen snapshot of a decision they do not understand, and they cannot move it when conditions change.
And the harder thing to copy is not in the product at all. By the time you are worth copying you have the audience, the trust and the distribution you built during those twenty attempts. The copier starts level with you on features and at zero on all of that. Same product, no one listening. That gap is the moat, not the code.
I am the cautionary tale for this one: I built heads-down for months and only started showing up in communities ten days before my launch (it is next Wednesday). It works, people are generous, but I now know what the silence cost me: every relationship I am building this week would have been compounding for months if I had started when I started building. So my answer as a fellow beginner: the right time is before you feel ready, but reframe what promoting means. Nobody experiences your early posts as promotion, that fear lives only in our heads (your salesy thread yesterday gave me the vocabulary for this). A question about the problem is not a pitch. Your waitlist-while-building approach is what I would copy next time, the validation alone is worth it. And on the copying fear: an idea that cannot survive being talked about was not going to survive the market either.
minimalist phone: reduce your screentime
@virko_kask The thing is – how would you promote that waitlist? :D Now, I have only 18 submissions :D
That is a great question that no doubt every product creator asks themselves. For me, I jumped in on day one after launching and never looked back. You have to believe in yourself before expecting others to believe in you.
minimalist phone: reduce your screentime
@janette_arsenault "You have to believe in yourself before expecting others to believe in you." – this is the most difficult part for me :D
I think you should start talking about the problem before the product is ready. Not in a “buy my product” way, but in a “this is the problem I’m seeing, this is what I’m testing, this is what users are telling me” way. That gives you feedback before you overbuild, and it also helps people understand why the product should exist before you ask them to try it.
jumping in from the other side of this, i shipped my product a while back (indie mac app, built solo) and honestly the promotion question doesnt end at launch, it just changes shape. pre launch, like most of this thread, the question is "is the problem real". post launch it becomes "why isnt distribution matching the thing i already validated". you'd think shipping something people actually pay for would make promotion easier. it doesnt, it just moves the goalposts. now instead of "will anyone want this" its "why dont the people who'd want this know it exists yet" what's helped, keep sharing the decisions not just the feature list. nobody's excited by a changelog. they're occasionally excited by "why i chose to do X the hard way" or "the thing i got wrong in the first version". basically the same advice as share the problem not the product further up this thread, it just doesnt stop being true after you ship the uncomfortable part, launch day doesnt feel like an ending or a beginning. it feels like the point where you realize promotion was never a phase, its a permanent job
I think the right time is when you understand the problem well enough to talk about it clearly.
You don’t need to promote the finished product from day one. But you should start sharing the problem, the assumptions you are testing, the users you are speaking to, and what you are learning. That is not really “selling.” It is building proof that the problem matters.
The product can change. The learning should start early.
I struggle with the internal battle between “this is a minimally viable product start now and but no one will care until I add x, y, &z.