FeedBok

Tom, the knowledge-base-first angle is strong. One homepage tweak: lead with the outcome before the feature list.

Hero idea: Cut repeat support tickets by making users check existing answers first.

Subhead idea: FeedBok searches your knowledge base, filters duplicate reports, and only forwards genuinely new issues with context.

Tiny FAQ idea: Will users feel blocked? No, they can still report; FeedBok just asks for one answer check first.

If useful, I can do a $2-$3 tiny copy note with 2-3 hero/CTA wording tweaks only. No big rewrite.

Thanks For Sharing Looks very Interesting.

Totally relate. Even just talking about my idea with friends was enough to reveal a problem. Their first reactions made it obvious I was obsessing over features nobody actually wanted. So I guess it's a useful first reality check before building too much.

This really hits home. The dashboard story is the perfect example — we all have features that feel obvious until you realize nobody actually asked for them.

The thing that changed my thinking was separating 'this sounds like a good idea' from 'people keep running into this without being asked.' The second one is the only signal that really matters early on.

Going through something similar right now with my own project — the hardest part is not building what excites you but what keeps showing up in conversations you didn't start.

Have you found that users are more honest in their feedback when they don't know you're tracking it?

This really resonates — especially the part about checking actual patterns instead of building based on assumptions.

One thing I didn’t expect in my own experience is how different “interest” vs “intent” really are. I had a few hundred followers pre-launch for a project, but converting that into actual users/backers has been much tougher than expected.

It’s made me rethink what signals actually matter early on — not just what people say, but what they actually do.

Curious — have you found any specific signals that consistently indicate real intent vs just passive interest?

This really resonates — especially the part about thinking something is “obvious” and then getting zero response after shipping it.

One thing I’ve been noticing is that the problem isn’t just tracking feedback, it’s that a lot of the most valuable signals never show up as structured feedback in the first place.

People don’t always submit feature requests — they complain in Reddit threads, ask vague questions, compare options, or drop little frustrations in comments.

In the space I’ve been looking at, the signal is everywhere, but it’s fragmented and hard to interpret. You end up either overbuilding based on noise or missing patterns that are actually there.

Curious — have you found that most of your “useful” insights come from direct feedback, or from patterns you had to piece together yourself?

This is a great example of why building faster doesn’t automatically mean building better.

AI has made it ridiculously easy to ship features, but it hasn’t improved judgment. If anything, it makes it easier to go down the wrong path faster.

The “no one complained about it in 5 months” point is gold. Most of us optimize for what’s visible (what we can design/build), not what’s actually painful.

Feels like the real skill now is:
pattern recognition > execution speed

Curious if you’ve noticed certain types of feedback being more reliable than others?

Building right now and have been dragging it out for longer than I ever expected. Only recently did we actually start getting real users and understanding what they wanted. I sometimes think being reactive when you have only a few users is also a distraction and that sometimes you do have to follow your gut but it is definitely a balancing act for sure.

Yeah, this is such a common trap — building what feels right vs what users actually keep asking for. The shift from scattered feedback to pattern-based decisions is honestly a big unlock.

Even we’ve been trying to stay closer to real signals instead of assumptions — especially early on when every feature feels important but not everything is actually needed.

Also sharing something I’m building in parallel — You have an idea. $19 puts it in a real competition. Winner gets a Tokyo trip (flights + hotel booked, minimum $500 guaranteed). Round just opened, so best odds right now: tokyolore.com

Ziraxo — Create AI-powered 3D images and models in seconds! Easy, fast, professional. Ziraxo.com

This really resonates. One of the hardest parts of building is separating a real repeated pain point from something that just sounds like a good idea. I’m currently at a similar stage with an AI product, and I’m realizing that pattern recognition in feedback matters much more than intuition.

We learned this the expensive way. Built a landing page auditor, got 8 signups, zero revenue. The tool worked perfectly. The audience didn't care enough to pay. What changed everything was going through 530+ competitor reviews and mapping the actual complaints by category. The patterns that emerged were completely different from what we assumed users wanted. Structured feedback is valuable but the best signal comes from what people complain about when they think nobody is building a solution.

Does this work as intended? Because, as it seems to me, such a module can now be created very quickly and efficiently directly in your application using Claude, Cursor, etc., and to be independent of external services.

the feedback loop was the real fix, not the tool itself. spent weeks building PM dashboard features nobody asked for before I started actually tracking what people complained about. the tool just makes you do the discipline.

This is such a big shift — moving from “idea-driven” building to “signal-driven” building.

I think a lot of us fall into that trap because building feels like progress, but without structured feedback it’s basically just well-informed guessing.

What you described about killing the dashboard redesign is key — not all good ideas are valuable problems. The absence of complaints is often a stronger signal than excitement.

I’ve been thinking about this more as a feedback density problem — one-off requests vs recurring patterns. The real leverage comes from spotting what keeps showing up unprompted.

Curious — have you found a good way to capture implicit feedback too? (like user behavior or drop-offs, not just what people say)

This is such a real shift.I’ve been going through something similar — realizing most of what I build is based on assumptions, not actual signals.Recently started experimenting with a different angle on the “finding users” side — pulling YC startups that are actively hiring and reaching out to founders there.Still early (only ~27 leads so far), but trying to see if catching people at the right moment changes how they respond.Curious — how are you getting your initial users right now?

Pretty cool idea, I was eager to try but google auth didnt let me in.

I think this can also be used a personal productivity tool. I can't tell you how often I lose valuable content because I don't remember how I came about the content and what social media platforms or website or email or text message I was consuming at the time the content was found. It could be the name of a great restaurant my friend sent me or a must read book I learned about somewhere (was it Discord? Reddit? One of the chat rooms?) or the diet or exercise of the day that looked really good but I can no loner find it.

p.s. I hope this suggestion goes to the right place on Feedbok!

This hit home. I spent a year building the wrong prayer app because I assumed I knew what churches needed. Shipped it, watched pastors try it once, and move on.

The turning point wasn't a new feature — it was shutting up and actually listening. I spent months talking to pastors and small group leaders with one question: "What do you actually need?" Turns out the answer was nothing I had built.

I scrapped the whole thing and rebuilt from scratch as SoapBox Prayer. Completely different product. The lesson for me: the feedback was always there, I just wasn't paying attention to the right signals.

Tools like FeedBok sound useful — but the hardest part isn't collecting feedback, it's being willing to throw away what you built when the feedback contradicts your assumptions. Congrats on shipping something that makes that easier.

This! Stopped guessing after building my feedback tool — now users vote/prioritize publicly. Growth exploded once I listened properly.

What tool helped you surface those small signals fastest?

Totally agree most founders are guessing instead of systematically listening.

One thing I notice is that even when feedback is collected, it often doesn’t translate into clear actions or changes that actually move metrics.

when you acted on user feedback for FeedBok, what type of changes had the biggest impact on retention or growth?

Just about time

The framing here is right. Most feedback tools are built to collect more signal. The real problem is making sense of what you already have. Repeat frustrations and unanswered questions are the most valuable data and they're usually buried in old threads and support tickets nobody revisits.

The shift from "what do users want" to "what are users already telling me that I'm not acting on" is a different way of operating. Good luck with this - curious what the most surprising pattern was when you finally started listening properly.

Totally agree sometimes the answers are already hiding in the feedback, we just need to listen properly. Curious: how do you separate the signals that really matter from the noise?

For founders looking to validate ideas or get co-builders involved, platforms like Creatives Takeover can help connect with early testers and developers.

Sign up for your service but it turned out that a free tier did not exist. So what the point in "Start for free" button?

What was the biggest surprise from user feedback that you didn't expect?

Talking to users is so important when building a SaaS. As founder we always think we know everything about our users, but most of the time it's false

I really like how you framed feedback as patterns rather than individual signals. Coming from VC/PE fund operations, I see the same thing: recurring friction usually hides in small, repeated issues rather than big blow‑ups. Curious how you distinguish early on between noise and the patterns that are actually worth acting on?

Hi Tom,

Per your posts, I really like how you framed feedback as patterns rather than individual signals.

Coming from VC/PE fund operations, I see something similar - recurring friction often shows up in small, repeated issues rather than major breakdowns.

Curious, how do you distinguish between noise vs meaningful patterns early on?

This comment was deleted 5 months ago

The distinction between "collect more feedback" and "make existing feedback visible" is sharp. Most tools optimize for volume — more surveys, more NPS pings, more popups. The actual problem for most builders isn't lack of feedback, it's that the signal is scattered across support emails, Twitter replies, Stripe churn reasons, and comments you half-read at 11pm.

We've seen this firsthand. Some of the most useful product insights we've gotten weren't in structured feedback at all — they were buried in how people described their problem in casual conversation. The phrasing someone uses when they're not "giving feedback" is often more honest than any survey response.

The part about retention improving once you focused on patterns makes sense. New features attract attention. Fixing repeated friction keeps people. But attention is louder than retention, so most builders default to building the shiny thing instead of fixing the quiet complaint.

One thing we're still figuring out ourselves: how do you separate signal from noise when the feedback volume is low? Early stage, you might get 5 messages a month. Three say different things. Two contradict each other. At that scale, every data point feels like it could be the pattern or just an outlier. How did you handle that before you had enough volume for real patterns to emerge?

neyi geliştireceğini bilmek ile doğru zamanı kollamak da önemlidir.

As a product manager by trade, curious to know how your tool helps with prioritization. Knowing what to build is one thing. Knowing when is another.

it's beautiful

The little, or in this case, quiet people are usually the bigger group, so I do like this idea.

This actually hits hard. Early on it always feels like the loudest feedback is the most important because it's the one you keep seeing or hearing. But most real problems are usually in the quiet patterns the small friction many users feel but never bother to write long feedback about.

Curious though, how did you start identifying those patterns in the beginning? Was it manual observation or did a tool help you see it clearly?

This resonates a lot.

It’s easy to overreact to the loudest feedback because it feels urgent, but often the biggest insights come from patterns in quieter behavior — where users drop off, hesitate, or abandon flows.

In my experience, those signals tend to reveal much more about product friction than direct complaints.

Hello founders,

I represent a group of companies looking to invest in promising startups and scalable projects.

If your startup has growth potential, feel free to share a brief overview or message me directly.

+62 831-5298-7392

Pattern recognition across feedback is underrated! most founders are reacting to individual complaints instead of seeing the trend

Really good point. The loudest users create urgency, but the quiet patterns usually point to what actually matters.

This is such a good observation. 👍

In many communities and products, the loudest users are usually just a small percentage of the audience. They can make it feel like their issues represent everyone, but often the real problems are the small frictions that many quiet users experience and never bother to report. A few people ask for very specific features, while the majority just silently stop using the product if something feels confusing or inconvenient.

That's a great idea. If I see a form where I can submit a feature suggestion, I'm happy to do so.

learned this the hard way. first SaaS failed partly because I was chasing the vocal feedback instead of looking at what most people silently bounced on. ran two independent analyses after — both pointed to the same quiet friction I'd completely missed

Interesting we will take a look at it.

The loudest users usually report the bugs, the quiet ones just disappear :)

Another important aspect of listening to feedback is listening to the customers who you want more of. Don't listen to everyone as you will build a mess. For example, free-tier users who never upgrade are not a good source of signal.

This mirrors something I kept noticing in freelance work. The clients who sent the most feedback emails were rarely the ones with the actual biggest problems. The clients who quietly stopped using parts of the product, or never came back after a few sessions, were the real signal. Nobody complained. They just left.

That's part of why I built automatic error capture into ReviseFlow. Waiting for someone to report a bug means you only hear from users motivated enough to complain. Capturing console errors and network failures automatically surfaces what's actually broken, even for users who say nothing.

How do you handle distinguishing genuine recurring patterns from just noisy one-off requests? That threshold feels hard to calibrate.

This is so true and we see this exact pattern with clients all the time.

Founder comes to us saying users are requesting feature X loudly. We build it. Then 3 months later same founder says feature X has almost zero usage.

The quiet users who just stopped opening the app after day 3 were the real signal. Nobody complained. They just left.

Loudest users are usually power users with very specific needs. They are valuable but they are not your average user. Building only for them is a trap.

We now push clients to look at drop off points in the app before looking at feature requests. Where people stop is more honest than what people say.

Good problem to solve with FeedBok honestly 😄

That's quite interesting. But right now I am using the following pattern: each user request/complain/bug I store in DB. After some time another agent, which runs every X minutes (using github actions), just uses some prompt, + skills + MCP access to github issues, groups feedback messages, ranks them, and recreates more structured/sorted github issues with different labels which I work on.
Does FeedBok has some extra features (in comparison to my approach)?

this is so true and honestly something most founders get backwards. we spent months chasing new acquisition channels when the real signal was sitting right in our support tickets and bug reports. the moment we started actually categorizing and prioritizing user complaints instead of just "noting" them, our retention improved way more than any new feature ever did.

curious how you handle the volume though — once you have hundreds of feedback items flowing in, how do you decide what's a pattern vs just one loud user?

Understanding what your user actually wants, is the key to make a more better prduct.

This really resonates! Turning user feedback into actionable direction is so often overlooked. Love how FeedBok focuses on fixing repeated friction instead of chasing random growth hacks.

Talking to your users is so important.