I've been building a side project called NewsSphere (https://newssphere.app/).
The original idea was pretty simple: organize news around stories instead of individual headlines and help people understand how events evolve over time.
I thought I was building a news visualization tool.
After sharing it publicly and talking to users, something surprising happened.
Almost nobody talked about the visualization.
Instead, people kept saying things like:
One user described the problem as seeing only fragments of a story over several days and losing the bigger picture.
Another pointed out that a single crypto story can generate dozens of headlines, but most people only see whichever headline their feed happens to show them.
The more feedback I collected, the more I started wondering whether the real problem isn't information overload.
Maybe it's context loss.
People don't seem to need more headlines.
They need help reconnecting the dots after they've missed part of the story.
This has probably been the biggest lesson from sharing NewsSphere so far:
Users rarely describe your product the way you do.
Sometimes the most valuable feedback isn't about improving the product.
It's about helping you understand the problem you're actually solving.
Has anyone else experienced users consistently describing their product differently than they did?
When users rename your product, that is not feedback to file away, it is your positioning handed to you for free. You built a "news visualization tool." The market told you it is a "catch me up" tool. The market wins that argument every time. The visualization is not the product anymore, it is the mechanism, the thing that lets you deliver the catch-up better than a plain summary would. So keep it, but stop leading with it. Rewrite the headline in their exact words. "Catch up on any story in 60 seconds" will out-convert anything with the word visualization in it. The job your users are hiring you for is "I fell behind and I feel out of the loop," and that anxiety is the wedge. Build the onboarding around relieving it in the first 30 seconds and you will know fast if you have something.
Yes, and the part you landed on is the valuable one: the user's word for it is the positioning you couldn't see from inside. You called it visualization because you built the mechanism. They called it "catch me up" because that's the job they hired it for. Those are rarely the same sentence, and the user's is almost always the one that sells.
The reframe from overload to context loss is the real find. Overload says "you're seeing too much," and the fix is filtering. Context loss says "you're seeing fragments out of order," and the fix is reconnection, a different product. Worth being honest with yourself about which one your feedback actually points at, because they pull the roadmap in opposite directions, and "catch me up" sounds a lot more like context loss than filtering.
The thing I'd watch now is the same trap I had to climb out of: it's tempting to keep the visualization framing because it's what you set out to build, and bolt "catch-up" on as a feature. Don't half-pivot. If the job users keep naming is reconnecting the thread after missing part of it, point the whole product at that and let the visualization be in service of it, not the headline.
To your question, yes, consistently. I built a support tool and users kept describing it as something that tells them whether they're personally exposed in the moment. Same gap: I named it by the mechanism, they named it by the fear it answered. I went with their word.
The 'fragments over several days, lost the bigger picture' line is the actual product — your users handed you the job, not the feature. I hit a smaller version of this with a lightweight iOS memo app I build solo: I thought I was shipping a note-taking tool, but people kept using the one-tap send as a 'get it out of my head before I lose it' inbox. The week I stopped calling it note-taking and designed for capture speed instead, the usage numbers finally moved. A rename like yours usually quietly kills half your roadmap too — which of your visualization features stop mattering once it's officially a catch-up tool?
ran into the same thing building BillWatch (billwatch-landing.vercel.app) - tracks federal bills that affect small businesses.
i thought i was building an "alert system for legislation." users kept saying things like "so i can catch up on laws that might hit me?" or "like a compliance heads-up thing?"
both descriptions are accurate but they point at different emotions. my framing was curiosity - you're staying on top of things. their framing was anxiety - you're behind and something is coming.
the catch-up framing won. now the homepage leans into that. the product is the same, but the user finds it instantly.
what you said about context loss is the real thing. it's not "there's too much news" - it's "i can't remember where i was in this story." that's a solvable, specific problem. the visualization might be the answer; just worth making sure the homepage says "you lost the thread" not "here is an interesting structure."
That's a really interesting distinction.
I hadn't thought about it in terms of emotion before, but I can definitely see what you mean.
A lot of my original thinking was around organizing information better, whereas much of the feedback has come from people describing the frustration of feeling behind or losing context.
The line that stood out to me was: "I can't remember where I was in this story."
That feels very close to what a lot of people have been describing, even if they've used different words.
Appreciate you sharing the example. It's given me another lens to think about the problem through.
I can totally relate to this. I'm a career-changer currently building a multi-brain self-dialogue feedback system. My whole motivation was that having multiple models debate and cross-validate each other would effectively reduce AI hallucinations.
But while testing it myself, something clicked: from the user's side, it just looks like a standard Q&A AI — you ask a question, you get an answer, and it doesn't feel all that remarkable. Even though the underlying logic of how responses are generated has completely shifted, the actual difference users perceive is nowhere near as dramatic as I imagined.
Just like you said, the most valuable feedback isn't about feature improvements. It's the kind that breaks you out of your own assumptions and shows you what problem you're really solving. This kind of perspective gap is something I think every builder has to run into firsthand before it truly sticks.
One thing that's become clear to me over the last couple of weeks is how easy it is to become attached to the implementation because you've spent so much time thinking about it.
For NewsSphere, I've spent months thinking about story clustering, timelines, persistence and visualization. Most users don't mention any of those things. They talk about the outcome they're looking for instead.
I think that's been one of the most valuable lessons from sharing the project publicly. Sometimes the gap between how builders think about a product and how users experience it is much larger than we expect.
Appreciate you sharing the example.
yes, constantly, and it's almost always more useful than it's comfortable. i built something I thought was a writing tool and users kept calling it a thinking tool, which sounds like a small distinction but completely changed what feature requests made sense to take seriously. the gap between your framing and theirs is usually where the actual product-market fit is hiding
That's a really interesting example.
On the surface, "writing tool" and "thinking tool" sound similar, but I can immediately see how they would lead to very different decisions about what to build next.
Originally I was focused on organizing and visualizing stories. The feedback I'm hearing is much more about recovering context, catching up, and understanding what changed.
I'm still trying to figure out how much of that is a positioning shift versus a product shift, but the gap itself has definitely become one of the most interesting things I'm learning.
This is a really interesting insight. I think founders often describe products in terms of features, while users describe them in terms of the outcome they're trying to achieve.
The shift from "news visualization" to "help me catch up on what I missed" feels like a much stronger problem statement. Did that feedback change your roadmap or how you're positioning the product?
I think it's changed my thinking more than the actual features so far.
The map, timelines and story grouping are still important, but I'm increasingly seeing them as a means to an end rather than the product itself.
A few weeks ago, I would have described NewsSphere as a way to organize and visualize stories. Today I'd probably describe it as helping people regain context on stories they've lost track of.
That shift is definitely influencing what I focus on next. Features like catch-up summaries, "what changed" views and helping people resume a story feel more aligned with the problem users are describing than simply making the visualization better.
The positioning is changing too. The more feedback I collect, the less I find myself talking about visualization and the more I find myself talking about context, story evolution and helping people catch up.
Still very early, but it's been one of the most useful lessons so far.
Mine got renamed too, and I made the expensive mistake of arguing with it. I built a memo app and kept calling it "notes"; users kept describing it as a way to "fire a thought to their own inbox." I defended the tidy "notes" story for months before I let their verb win. Every time I explained what it "really" was, I was quietly translating away the exact words that would have sold it. Users aren't misunderstanding your product — they're handing you the positioning, free.
The phrase "let their verb win" really stood out to me.
Looking back, a lot of the feedback I've received has been verbs rather than product descriptions, whereas I've naturally been thinking in terms of maps, timelines, clustering and story evolution.
What's interesting is that people from completely different communities keep using similar language, which makes me think there's probably something important there.
Appreciate the perspective. It's given me a lot to think about.
Yep. Valuable take-aways. Since I'm using ClaudeCode to do news monitoring, I'm wondering what's your edge over that.
That's a good question.
I think Claude, ChatGPT and similar tools are already very good at answering questions when you know what you're looking for.
What I'm exploring with NewsSphere is a slightly different problem: helping people discover and regain context on stories they may not even realize they've missed.
For example, if I ask Claude about a specific story, it can usually help me understand it. But NewsSphere is trying to continuously organize coverage into evolving stories, show what changed over time, and make it easier to see the bigger picture across many developments.
Whether that's actually a meaningful advantage is something I'm still validating. It's entirely possible that AI assistants become part of the solution rather than the thing NewsSphere competes against.
Out of curiosity, how are you using ClaudeCode for news monitoring today?
Basically I have a personal knowledge base to keep track of everything I have already know. It will automatically search for topics I know and add what's new by comparing to what I have already known. We can chat more if you are interested.
Had almost the same experience. I built My Rundown thinking the core feature was AI summarization. Users who stuck around described it differently: "I don't have to remember to open another app." The delivery model was the thing, not the AI.
Took me a while to stop leading with "AI summaries" and start leading with "your reading list shows up in your inbox." Same product, completely different framing.
Your catch up framing is probably the right one. "Help me understand what changed" is a much more specific job than "visualize the news."
That's a really helpful example.
What resonates with me is that the underlying product didn't change, but the way users described the value was completely different from how the founder described it.
I'm starting to see a similar pattern with NewsSphere. I've spent a lot of time thinking about stories, timelines, clustering and visualization, but users almost never talk about those things.
Appreciate you sharing the experience.
Worth asking directly: when users who stuck around describe NewsSphere to
someone else, what do they actually say? Not the features, but the sentence
they use to explain why they use it.
That gap between what you built and how they describe it could be where the
real positioning is hiding.
That's a really interesting question. To be honest, I don't know yet because I'm still very early and don't have many repeat users.
What I do know is that when people describe the problem back to me, they say things like:
That might not be the same as how existing users would recommend it to a friend, but it's probably the closest signal I have right now.
Definitely something I should start paying more attention to as I get more users.
"Catch me up" and "help me understand what changed" are actually more specific
than most founders get at that stage. A lot of people describe the problem in
feature terms (I want timelines, I want clustering). The fact that yours are
phrased as jobs is a good sign.
The repeat user signal is worth watching for later, but honestly that problem
language you already have is probably close enough to build the positioning
from. If that's what people say when they describe the pain, that's what should
be in the headline.
This matches something I keep running into. Users don't categorize products by their architecture, they categorize them by the moment they reach for them.
That's a great way of putting it.
The more feedback I've collected, the more I've realized people rarely describe NewsSphere in terms of what it is. They describe the situation they're in when they want it.
Things like:
They're describing a moment rather than a product category.
I'm still trying to understand exactly what that moment is, but it's definitely changed how I'm thinking about the product.
You've already had the important realization — users named the job (catch me up) while you named the mechanism (visualization). That gap is the whole post and you read it correctly. So the useful thing now is what you do with it.
The reframe has direct consequences for everything downstream:
Positioning: "news visualization tool" describes how it works. "Catch up on any story in 30 seconds" describes what they get. Your users handed you the hero copy verbatim — "catch me up" and "what changed" are the literal words to put on the page. Stop translating them into your language.
Product priorities shift too. If the job is context-recovery, the visualization is a feature, not the point. The most valuable thing becomes "here's what you missed and why it matters," not "here's a pretty timeline." Some of what you built for the visualization vision might be polish on the wrong axis.
The wedge gets sharper by category. You mentioned crypto — a single story spawning dozens of headlines is the acute version of context loss. Crypto, politics, ongoing legal cases, sports seasons — fast-moving multi-headline stories are where "I lost the thread" hurts most. "Catch up on any story" is broad. "Never lose the thread on a developing [crypto/political] story" is a wedge with a specific audience who feels it daily.
On your actual question — yes, this is one of the most common founder experiences, and the ones who win are the ones who let users rename the product. The founders who lose argue with their users about what the product "really" is.
What's the catch-up moment people described — daily check-in, returning after a week away, or jumping into a story they never followed? Each is a different product.
I appreciate this comment.
The distinction between the job and the mechanism is probably one of the biggest things I've learned from sharing the product so far.
Originally I spent a lot of time thinking about how to organize and visualize stories, but very few users have talked about the visualization itself. They almost always describe the outcome they're looking for instead.
Your question about the catch-up moment is a good one, and honestly I don't think I know the answer yet.
The strongest signal so far seems to be people who have missed part of a story and want to quickly understand what changed. I've also seen some examples of people suddenly wanting context on a story they've never followed before.
I haven't seen much evidence of a daily habit use case yet, which is one of the things I'm trying to learn.
Appreciate the thoughtful response. It's given me another angle to think about.
The two patterns you named are actually two different products, worth separating before building for both.
"Missed part of a story I was following" is catch-up. User has context, lost the thread, wants the delta. Job is "what changed since I last looked." Retention-friendly, because following a story implies coming back.
"Need context on a story I never followed" is onboarding. No prior context, wants the whole arc compressed. Acquisition-friendly but one-and-done unless the story keeps developing.
They feel similar but the mechanics differ. Catch-up needs to know what you've already seen (state, personalization). Onboarding assumes zero knowledge and builds the arc from scratch. Hard to nail both early.
The missing daily habit isn't a problem, it's information: this is likely event-driven, not daily. People come when they've missed something or a big story breaks. Different retention model than a news app, so growth should lean into alerts ("you've missed 4 updates on X") rather than fighting for daily opens you won't get.
If you want to pressure-test which job to lead with, that's what HiveMind is built for. https://hivemind.myosin.xyz/auth/signup
Which pattern showed up more in the conversations?
What stood out to me isn't that users described the product differently.
It's that they may be describing a different problem altogether.
Those sound similar on the surface, but they can pull a product in very different directions once you start building around them.
That's a really good observation.
The more feedback I've received, the more I've been wondering about exactly that.
The original idea started with organizing news around stories rather than individual headlines, but many users seem much more focused on the experience of losing context and trying to catch up after they've missed part of a story.
Those sound related, but I agree they could lead in different directions.
At the moment I'm trying to resist jumping to conclusions and collect more evidence, but it's definitely one of the biggest things I'm thinking about right now.
Appreciate the perspective.
I think that's a sensible instinct.
The reason it caught my attention is that I've seen products end up in very different places depending on which of those explanations they build around.
Happy to send over the fuller thought if it's useful — just drop your email.
I'd love to hear it.
That comment actually resonated with me because it's something I've been thinking about since I started getting feedback from users.
Feel free to send it over. My email is [email protected]
Appreciate you taking the time.
Sent it over.