I posted a boring intro in a 456k-person community. One line got all the reaction

Had the mirror image of this. Posted about winning a chargeback and then losing the customer anyway. The post itself got nothing, but the replies telling me why would you expect them to stay outscored it. One link took over, it just happened to be the one that killed the pitch. Still haven't found a framing that works.

This resonated. I’ve seen the same pattern a few times: the line you almost cut is the one that actually lands.
A feature list forces the reader to do the imaginative work. A single concrete scenario (“someone who doesn’t know how to build anything just talks and gets a working funnel”) does that work for them — and immediately surfaces the real questions about reliability and handoff.
Curious how you’re thinking about the “who’s watching when it fails” part as you double down on that mechanism.

That one line works because it names a job to be done, not a feature. An onboarding agent is something someone has needed for months and never said out loud, and your post became the first time they heard anyone solve it.

A feature rundown describes what you built. A job names what people are stuck on. The store builder is useful to people who already know they want to build stores. The onboarding agent is useful to people who know they have onboarding and hate doing it manually.

The comment ratio you are seeing is real signal. People do not argue about solved problems, so no questions on the CRM or store. People argue about whether a solution actually works, which is what you got: how does it handle vague requests, what about after launch, how much does it cost. Those are the objections that were sitting silently in their heads.

Name the job, not the solution. Your next post can do it in one sentence and catch the same 30 likes.

Classic feature list trap! People don't care about "all-in-one" platform claims anymore, they care about solving a single painful task zero-friction. Double down on that specific onboarding story, build your whole marketing angle around it, and let the rest of the features just be pleasant surprises under the hood!

You pitched a platform, but people don't fall in love with platforms they fall in love with a moment they can picture themselves in. The questions you got are more valuable than the likes.Notice what people actually asked: not "is this a good idea" but "how do you handle a vague request" and "who's watching when it breaks." That's not enthusiasm, that's due diligence from people who are already halfway to trying it. They're not evaluating the concept, they're evaluating the risk of the concept failing on their business. That's a much further-along audience than 30 likes suggests. Before you rewrite the whole positioning around this one feature, I'd test the same "one concrete scenario" framing in a different room and see if it's the feature that lands or just that this specific audience loves agent demos.

The reliability answer is the part I would pressure-test before the deeper piece, because it may be answering a narrower question than the one being asked.

You described it as: if something fails on the backend, like a write to a sheet not going through, it triggers a notification right at that moment. That is a failure that raises. The class StefanStefanos named, silent breakage, which they said usually kills trust faster than a visible error, is the one where nothing throws, so there is no moment for a notifier to fire at.

I got this wrong on my own setup. An unattended job on a second machine ran for twelve hours, completed, and wrote nothing back. Nothing errored. From where I sat it looked identical to a job that died on the first step. I wrote "silent for two and a half days" in my record and treated it as stopped. It had not stopped. The result was sitting on the machine, unsent, and the next run would have overwritten it, because the output folder had a fixed name. What would have caught it was not a better error handler. It was a heartbeat every thirty minutes and a dead man's switch that emails a human after two hours of silence, an alarm on absence rather than on failure, plus a rule that the job refuses to start if its output folder is not empty.

Two things that fell out of that, for what they are worth here.

Your dashboard shows agent-handled against human-handed-off. The state I ended up having to count separately was the one that is neither yet: still in flight, and has been for a while. If an interaction can sit there, it either gets its own number or it stays invisible until it lands in a bucket.

And on the response-time half of what astudio asked for: the number I can stand behind is time to detect silence. Time to notify on failure only covers the failures I have already seen.

That split shows up in search too, and it costs people months.

A title earns the ranking from a machine reading for topic fit. The click is decided by a human scanning nine other titles at the same time. Two different judges, and nearly everyone only tunes the first one. You end up sitting at position 8 with a CTR under 2 percent, which looks like a rank problem and is really a sameness problem. Your feature rundown ranked fine. The onboarding agent line is what got picked.

The site version of your experiment: open Search Console, sort queries by impressions, find any query where you are in the top ten with a CTR under 2 percent. Search it and read your title next to its neighbours. If you cannot say in one sentence what yours offers that the others do not, the title is the leak, not the position.

The part of your result I would sit with is that the winning line was the aside. The stuff written quickly tends to be the specific stuff, and specific is what gets a reaction. Worth combing your old posts and docs for those sentences before writing anything new.

If you want the same read across channels rather than one page at a time, contentmation.com/score benchmarks a site across six of them free with no login. It only tells you where the gap is though, it will not write the line for you.

You measured the pitch by feature-list attention, but your actual signal was "can I visualize myself using this right now." That's why the onboarding agent landed - it's a concrete moment someone can picture themselves in, not an abstract capability. Features require the reader to do the translation work from concept to their specific problem. A scenario does that work for them. That shift from abstract features to concrete scenarios is how you measure relevance. Teams miss this constantly and keep adding feature descriptions when the signal they're missing is "show me a situation where I'm the person who wins."

This is actually something I'm trying to figure out right now. I'm building CodeCard, and I've noticed that explaining what it is isn't necessarily the same as explaining why someone should care. Curious how you guys figured out the one-liner that actually makes people stop scrolling.

Worth being careful about what those 21 comments actually validate. Reliability questions ("what if it misreads a vague request", "who takes over when it breaks") are cheap to ask and cost nothing to walk away from, so they signal interest in the category more than intent to buy your version of it — I've had threads like that produce huge engagement and near-zero trials. The more useful read is that those recurring questions are a free spec: people are telling you the onboarding agent needs a visible run log, an explicit escalation path, and some notion of "here's what it did and why" before they'll stake a real business on it, and shipping that surface is probably higher leverage than the deeper write-up. I'd also separate narrowing the pitch from narrowing the product: leading with one concrete scenario is right, but if that wedge pulls in non-technical users, support load becomes the real constraint, not positioning. How many of those 21 commenters actually signed up or DM'd you, and in the threads where the same three questions appeared, which one came up first? The ordering usually reveals the primary objection, and that's the line your next post should open with.

The shift from "can it do that?" to "who's watching when it breaks?" is a really specific signal. It means you already cleared the belief hurdle. People aren't evaluating whether AI-builds-your-funnel is possible. They believe it. What they're vetting now is whether it's safe to stake something real on.

In sales, that's actually the harder conversation to trigger, and the more valuable one. Feature lists keep people evaluating capability. One concrete scenario drops them straight into imagining the risk of trusting it. That's where buying intent lives.

When I've hit moments like that in a pitch, the right move was to stop explaining the rest of the product and stay in that one scenario until people had answered their own doubts. The store builder gets its turn once they trust the core thing.

Good instinct building the dedicated piece around it.

Selling services to small businesses taught me the same lesson from the other side. Owners never respond to the capability list; they respond to a scene they recognise. The line that gets repeated back to me in first calls is "you are the booking system: customers text you and you retype it into a calendar." Nobody has ever quoted the tech stack back to me. One thing I'd add to the good points above: "who's watching when it breaks" isn't really a content question, it's an operations promise. For non-technical buyers the reassuring answer is boringly specific: a named human, a response time, and a plain description of what the agent does when it can't parse the request (asks a follow-up, falls back to a form, or stops and flags it). If you can put that on the page as a commitment rather than a feature, the "just talk to it" pitch stops sounding like magic and starts sounding like a service they can rely on.

We've seen the same from the outside: we went through a couple hundred indie hacker launch posts, and the ones that pulled replies were the ones built around one scene you could picture — with the same 2-3 "what happens when it breaks" questions repeating in the comments. Once we noticed it, those recurring questions became the content plan and the landing-page headline. Did yours turn out to be the questions people asked before signing up, or after?

The questions are the asset here, not just the line. Every question ("how does it handle a vague request?", "what happens when it fails?") is a pre-written objection — which means it's also a pre-written outline for both the deeper piece and your landing page FAQ. I'd lift the three recurring questions as H2s in the follow-up and answer each with a screenshot or 30-second clip of the actual behavior.

One more angle: the reason nobody debated the premise is that this community already grants it. That tells you the pitch's job is no longer "convince them AI can build funnels" but "convince them yours won't embarrass them in front of their client." That's a much narrower — and more winnable — argument. The follow-up piece should be 90% failure-mode handling, 10% capability.

The interesting part is that people didn’t react to the feature itself, but to the uncertainty around it. “Just tell it what you want” sounds simple, but the real value is whether that simplicity survives real-world use. I think you found a much stronger story than the original feature list.

The tell isn't that they asked about the onboarding agent, it's that every question was about failure modes. Running Microsoft migrations for two decades, the feature never closed the deal. What closed it was answering who picks up the phone when it breaks at 2am. I'd write your deeper piece about the handoff and the failure path, not the magic moment.

Yes, almost exactly this.

In June I posted a feature list here for my lead tool: signal detection, enrichment, a growing dataset, outreach drafts, mobile research. Two people wrote long replies and both skipped the list and went straight for one phrase. One put it as the difference between who exists and who is moving right now. The other told me I would land in the "another lead tool" bucket unless I led with that.

What I did was take it literally. I stopped describing features and asked what would have to be true for "moving right now" to hold up. It needs a date. So I measured where dates actually come from, on 60 companies: RSS, the WordPress API, JSON-LD, og:modified, the Last-Modified header, news search, job ads. Six of the seven were close to empty. The official business register was the one that worked, with 7 percent of leads carrying a dated event in the last 30 days and 20 percent within 90.

So the aside did more than change the pitch. It decided what I built for the next three months.

It happened again this morning on Reddit, at a smaller scale. I posted new-company numbers for Norway and mentioned in passing that only 36 of 2,589 new companies had listed a website. Every question in the thread ended up being about contact details. How many put in a mobile number? 67.

One thing I would add to your approach: when one line takes over, check whether the thing people are excited about exists in the product at the level they are picturing. For me it did not, not fully. The excitement was a spec.

You already have a useful outline for the follow-up piece in those three recurring questions. Keeping them in the readers' own words as headings would make it easy for the same people to find their answer. Hope the deeper piece goes well.

This is a good reminder that distribution often surfaces the user’s job-to-be-done before the founder’s category label does. I’d cluster the questions by underlying trigger, then rewrite the lead around the most repeated trigger and test whether it attracts the same quality of replies in a second community.

The repeated questions might be as useful as the feature people reacted to. They seem less worried about whether the agent can build something and more about what happens when it gets things wrong. That feels like a pretty strong signal that reliability and human fallback should be part of the pitch too.

The reaction is strong enough to treat as more than a copywriting signal, especially with the same questions repeating. Have any of the people engaging with that onboarding-agent message actually tried the product or asked to use it, or is the evidence still limited to interest in the idea?