Your Product Might Not Need More Features — It Might Need More Discovery

There is a third option missing here, and it is the most common one I see: the product is getting found and people bounce because the promise on the page does not match a problem they had that morning. Another directory listing moves traffic, not intent, and directory traffic almost never retains past week four. Before you spend a month on features or a month on distribution, pull the last 20 people who signed up and did nothing and ask what they expected, because the answer is usually a positioning fix that takes a day.

Discovery channels are chosen by what you measure, not by what actually works. Most teams measure reach: which platform has the biggest audience? But reach isn't the right measurement for discoverability.

The right measurement is resonance-to-reach ratio: what fraction of reachable people actually engage? A niche community with 60% engagement beats a massive audience with 0.5% engagement every time. Your discovery channel choice should be driven by which measurement system reveals the truth about where your specific users actually pay attention.

This is so true. It’s easy for founders to convince themselves that one more feature will be the thing that unlocks growth, when the real problem is often that not enough people know the product exists.

Distribution should be part of the product-building process, not something you think about after the product is “finished.”

informative, thanks man

Agreed, with one caveat I ran into this week that I rarely see discussed: for some products discovery has a direct marginal cost, and that changes which advice applies.

My app's learning side is free forever, and the paid part is a real-time voice tutor. Every new signup gets 30 free tutor minutes. Those minutes are real money to me, roughly $0.75 to $1.74 per account in provider fees, whether or not that person ever pays.

So "just get more users" is not a neutral instruction in my case. A thousand signups that don't convert is a bill between $750 and $1,740. And my voice provider caps me at five simultaneous conversations, so the thousand-and-first person gets refused anyway.

I don't think this invalidates the discovery-over-features point, which I agree with. But if your product has a variable cost per free user, the honest version is: get discovery right AND know your cost per free user before you succeed at it. Getting the first right without the second is how people blow up on their own launch.

This is something I'm actively trying to avoid with CodeCard. It's ridiculously easy to keep adding features when you're building your own product, especially when you can already see 20 things you'd like to add. I'm trying to get people using the MVP first and let their feedback determine what gets built next.

"Building feels like progress, distribution feels like rejection" is the exact trap, and naming it that clearly is useful.

The asymmetry is mostly psychological. When you build, you can see the output. When you do distribution, you're often posting into silence with a feedback loop measured in weeks. So builders gravitate toward the thing that gives immediate visible proof of work.

The equal-time heuristic is a reasonable counter, but the harder version starts earlier. First users should come before first features — not as validation theatre, but as actual people annoyed enough to try something half-built. That's where the real product roadmap comes from. Every thread where someone complained about the problem and you answered is a user interview you didn't have to schedule.

What were the things you heard in those public threads that changed what you built?

Building is the fun part, distribution is the real work. Spot on

Improving onboarding, visibility, and reaching communities where target users already discuss the problem can reveal what features actually matter.

This is the trap I fell into more than once — treating "nobody's converting"
as a product problem when it was actually a discovery problem. Added a
feature, shipped it, conversion didn't move, because the handful of people
who'd already found the product weren't the bottleneck — the thousands who
hadn't were.

The distinction I'd push on: discovery platforms fix "nobody found it,"
but they don't fix "the people who found it didn't feel it was for them."
Curious how Launch Nest handles that second failure mode — is it purely
a listing/discovery surface, or does it also help with targeting the
right audience once someone lands on the page?

All the directories with traffic have you wait 3-6 months to get a product posted. They want $50 payment, link to their website or some other thing to "skip the queue". We all have bots now that can autopost, but is posting on them even worth it?

This is a good reminder to separate demand and discoverability from product gaps. Before adding features, I’d look at which pages get visits and where prospective users drop off; that seems like a cheaper signal than building another feature.

The idea that a product may need better discovery rather than more features is a useful perspective for product teams. Improving onboarding, navigation, search, and helping users understand existing functionality can sometimes create more value than continually adding new features.

This is the trap most of us fall into: building feels like progress, distribution feels like rejection.

What finally shifted it for me: I started treating "where do users already complain about this problem?" as a feature request. Turns out my users were asking for things in public forums for months — I just wasn't there to hear it.

A rule that helped: every hour of building gets an hour of showing up where the problem is discussed. Not pitching — answering. The product roadmap literally rewrote itself from those threads.

Features get you retention. Discovery gets you users. And users are the only ones who can tell you which features actually matter.