Connect with the Product Hunt community

When a free user bounces, it's a data point. When a paying customer cancels, it feels personal.

We realized most cancellation feedback wasn't about bugs it was about our tool failing become a daily habit. Fixing workflow fit is harder than shipping code.

Does the sting of churn ever go away, or do you just analyze exit feedback faster?

I was wondering where I can see the last new posts on Producthunt. Especially the new projects that are being launched. I'm very much interested in the newest project, because the ones on top of the leaderbord already are known by many.
Thanks for your help, greetings Verdictfootball

Hi guys, if the demo at a product launch dinner doesn't go well, due to some errors/issues, how do you deal with it? A lot of time is spent on invited investors, other company leads, prospective customers, etc. and it's disheartening when the demo doesn't go as planned. How to deal with this?

We built automated alerts, summaries, and email digest triggers thinking we were keeping users engaged. But cancellation feedback showed the exact opposite.

Instead of bringing users back our notifications were creating inbox noise, causing users to mark us as spam or cancel just to clear their mental clutter. They liked the product, but hated the daily noise around it.

For founders who have optimized re-engagement: how do you design smart notification frequencies that build habits without causing fatigue?

Our email list hit 40k subscribers, but open rates dropped below 12%. I was terrified to clean the list thinking a big subscriber count meant more potential buyers.

We finally deleted 12k people who hadn't opened a single email in six months. right after open rates jumped to 28% and weekly email revenue went up by 15% because main inbox placement improved.

How often do you prune inactive contacts from your newsletter list?

Built a quick invoice app using cursor over the weekend and everything worked great on my end.

Then two people tried editing at the same time and one ended up overwriting the other's changes without any warning. Turns out AI coders won't add multi-user checks unless you explicitly ask for them.

Do you guys have a short prompt checklist to catch shared state issues before testing with real users?

No first paying customer here yet, so this is less a story and more a suspicion I want to test.

When you start out, the first people you talk to are usually people who already like you. They re warm, they totally get it, and they say they d use it.

I m starting to think those conversations are great for learning and terrible for validating. People who like you are bad at telling you they won t pay.

Genuinely curious. Most rejections I've seen are some version of "we've decided to move in another direction" and nothing else.

Has anyone ever gotten actual, useful feedback after an interview? What did it say, and did it change how you interviewed next time?

I logged every indexing API notification for 58 days. 551 total. 187 were for pages already indexed weeks earlier. My sitemap was regenerating on every deploy, so the API kept seeing "new" URLs that were unchanged.

I gated the build behind a content hash. Notifications dropped to 12 the next week. What's your duplicate notification story?

When we released our public beta our inbox filled up with excited users asking for custom integrations, dark mode and complicated export formats. We spent three weeks building the popular feature only to see no one use it.

We found out that users suggest solutions based on their specific limited workflows, not the main problem they are trying to solve. They ask for a horse when they really need a car.

We changed how we handled feedback to ask "what are you trying to accomplish today?" Of "what feature do you want next?". That change uncovered hidden problems we never would have found from lists of feature requests.

Pay attention to user frustration. Think of their suggested features as signs of a problem, not the problem itself.

It's so easy to fall into the trap of automating everything just because you can write a script for it.

I automated our weekly invoice sorting process but it turned out that going through those files manually was the only time I caught subtle client trends and bugs.

Once it became fully automated, I stopped looking at those details altogether. Are there certain tasks you purposely refuse to automate now because you need eyes on them?

Launch day is exciting, but traffic can fade fast. For those of you who ve launched, what did you do in the first 15-30 days that made the biggest difference to retention and expansion of user base?

I m especially curious whether things like free credits or referral rewards moved the needle for you, or whether community and onboarding mattered more. I'm thinking of going down the free credits route but would love some inputs.
Would love to hear what worked and what didn't.

Focusing on signup momentum feels amazing early on, but cancellations hit differently once revenue is involved.

We used to celebrate new user milestones. Then the paid tier launched and churn taught us a lesson: people don't leave because of missing features. They leave because our product didn't fit into their daily workday routine.

Fixing actual workflow friction is the real bottleneck.

Do experienced founders get used to churn, or do you just build faster ways to analyze cancellation reasons?

It's so easy to use "we need more features" as a comforting excuse when retention dips, because building a feature feels like productive work.

But a lot of the time churn happens simply because the tool creates extra steps instead of removing them.

If a user has to break their daily routine just to fit your software into their day they're going to bounce no matter how good your roadmap looks.

What specific questions do you ask during churn feedback to get past the fake excuses and find the real workflow problem?

It feels great seeing high signup numbers every week, but watching 60% of a specific user segment churn after month one is demoralizing.

We realized these users were signing up with expectations our tool was never built to solve. They churn not because the product is bad, but because they were the wrong audience from day one and their feedback was polluting our roadmap.

How do you implement qualification gates or repositioning early in the funnel without turning away good prospects?

A few years ago, juniors cut their teeth on writing basic CRUD endpoints, fixing simple UI bugs, and writing unit tests. Now, an LLM can spin those up in ten seconds. Because of this, companies are raising the bar for entry-level roles to what used to be mid-level expectations, locking fresh grads out entirely. We started a micro-internship program focused purely on code review and refactoring AI output, and it completely changed our talent pipeline.
How is your organization adjusting its junior hiring model now that AI handles the boilerplate?

First post here. Been browsing Product Hunt for a while without an account and finally made one.

Small frustration. So many products won't let you see anything until you make an account. No demo, no screenshots of the actual interface, no way to poke around. Just a signup form and a promise.

Half the time I sign up, look around for two minutes, and realize it's not for me. Now they have my email and I have nothing. I've started just closing the tab when signup is the first step, even if the product looked interesting.

Wanted to know how other people deal with this. Will you sign up to try something you're on the fence about, or does that immediately kill it for you? And has a product ever won you over with just a good demo, no account needed?

When customers ask for features, our instinct is to build them to keep everyone happy. But over time, our core product started feeling cluttered and overwhelming for new paid signups.

The hard truth is that every new toggle or tab adds cognitive load. Users aren't canceling because we lack features; they're churning because the tool started feeling like work instead of solution.

For founders who have pruned their product. how do you balance power user feature requests against keeping the core experience clean and friction-free?

I used to waste way too much time looking for clever distribution tricks or viral loops, hoping I could skip the slow grind. But whenever I see a success story broken down the hack usually turns out to be pretty hands-on work personally onboarding users replying to feedback and actually writing good content.

Sometimes calling basic consistent marketing a growth hack makes it sound like there's some secret shortcut to traction.

curious if anyone here has seen a tactic actually work long-term that wasn't just good old-fashioned work in disguise?

Doing a massive refactor that ships zero new features is mentally exhausting especially when your task board stays completely static for days.

It feels like you're falling behind while everyone else is shipping cool stuff. But you're so right about the payoff later touching that messy code cuts your future development time in half.

My biggest struggle is always justifying that time to stakeholders who only care about feature lists.

Do you have a specific way you pitch clean-up work to keep the pressure off?

This hits way too close to home. I used to give textbook technical answers to client bugs, only to realize later that their entire architecture was completely different from what I assumed.

Giving the technically right solution for the wrong setup just creates more confusion. Now I try to make them explain their whole workflow first before writing a single line of code.

Have you found a good way to steer users away from asking the wrong technical questions in the first place?

Looking at who pays in my app, the split by language surprised me. Spanish-speaking users convert at around 12%, Arabic-speaking users at about 2.5%, even though Arabic users found the app on their own and used it a lot.

I never localized the store page for either.

Is this mostly purchasing power, store pricing tiers by country, or trust in a small unknown app?

During our days we would send surveys asking our users what new tools they wanted us to add to the platform. We ended up building a reporting dashboard because a dozen vocal customers requested it.

After spending three weeks developing the dashboard only two of those customers actually used it more than once. We learned the way that customers are excellent at identifying their frustrations but terrible, at designing software solutions.

We changed our feedback process to focus entirely on their workflow instead of feature wishlists. Now we only ask them to describe the tedious part of their week or the task that takes them the longest to finish.

This subtle shift gave us a deeper understanding of their underlying problems. We recently built an automated export function based on workflow feedback and it immediately became our most popular feature of the year.

One of the things that I have done is instruct my assistant to give me an algorithm, data-structure, distributed-system, or system-design problems that align with my current project.

The goal is to define invariants, choose the structure, reason about complexity and failure cases, rather than have the assistant do all of the thinking.

Some that I recently worked on:

• Counting Bloom Filter design for a specified false-positive rate, deletion, counter saturation, and memory constraints.

• Consistent Hashing with Virtual Nodes distribute agent jobs/provider traffic while minimizing reassignment when workers enter or leave the pool.

• Topological Sort + Cycle Detection for Agent DAGs validate dynamically assembled agent workflows, detect illegal dependency cycles, and produce a valid execution order.

• Weighted Reservoir Sampling select representative evidence/content from a stream under bounded memory when items have different priorities or relevance weights.

• Interval/Dependency Graph for Evidence Invalidation propagate a changed or revoked source through dependent claims, proposals, approvals, and released artifacts without recomputing unaffected branches.

Testing with friends and fellow developers is a massive trap.

They always tell you the app looks great and the idea is solid because they want to support you not because they actually face the problem you're solving.

We built an entire feature based on positive feedback from a non-target audience, and when we launched publicly real users didn't care about it at all. It took months to pivot back.

How do you stop yourself from listening to polite feedback instead of real market signals?