How do you decide which product idea to build – and which one to kill?

Mainly based on user interviews and data from the market. The product I launched today is based on my experience working in the world of marketing which makes it easier in the sense as far as knowing the market (although there always is room to learn of course)

Do you think founders are better at identifying prob they personally experience versus broader market probs?

For me the signal was: are people already doing this manually, inefficiently?

I'm building Nibble, a recall and food safety tracking app. Before I started, I looked at how people actually find out about recalls. The answer was: they don't. Or they stumble across a government press release three weeks late. Or they check one agency's website and miss that the same product was recalled in another country under a different name.

There's no central place for it. Just 40+ government agencies across 13 countries, each with their own format, their own schedule, their own buried website. Parents with kids who have allergies, people with celiac, anyone who actually cares about what they're eating... they were all doing the same thing: manually checking scattered government sites and hoping they didn't miss anything.

That was enough for me. I didn't need a validation framework. When the workaround is that painful and that many people are stuck with it, the idea kind of validates itself.

The harder question for me isn't "should I build this" but "when do I stop expanding scope." 13 countries, 5 categories, 41 data sources. At some point you have to ship what you have instead of chasing completeness. That's the part I'm still figuring out.

For specialist B2B products, "worth building" and "demand exists" tell you different things, and it matters which one you're answering.

Demand validation (ProblemHunt, 404tomb, polls) tells you a problem is real for some number of people. But for niche practitioner products — financial models, professional templates, vertical tools — that signal is structurally noisy. The buyer often doesn't know they need it until they're sitting in front of a deal at 11pm and the model they have doesn't sculpt DSCR the way the lender wants. Pre-validating that moment via survey just gets you the textbook answer; the real validation is whether anyone uses it once it exists.

What I've learned shipping specialist financial model templates: the kill signal isn't "no demand" — it's "no one is asking the exact question the product answers." A model template that does generic three-statement is useless because every analyst can build one. A model template that handles construction-phase interest capitalisation with the COD transfer cleanly is useful because almost nobody builds that without making mistakes the first three times. The narrower the moment-of-use, the easier the kill/keep decision.

The MVP timing question is downstream of that. If your MVP targets a moment-of-use that practitioners will recognise, six weeks is usually enough — you'll know from response patterns (which feature do they ask about first) whether it lands. If it targets a "general productivity gain" or "everyone could use this," six months won't tell you, because the signal is too diffuse.

The cleanest filter I use: can I name three specific scenarios where someone would search for this exact thing? If I can't, the idea is probably noise. If I can — and the search terms have low competition because the moment is niche enough not to attract generic competitors — that's the signal to build.

The validation step is usually the first thing we skip because it feels slow, but it's probably the one that saves the most time in the long run.

honestly... one thing i’ve started paying a lot more attention to is whether the problem keeps coming up naturally in conversations

if multiple people keep complaining about the same workflow/problem without being prompted, that usually feels like a much stronger signal than “this market is huge”

also feels like distribution matters almost as much as the idea now 😅 there are probably thousands of decent products that never got enough attention to even properly validate whether the idea was good or bad

• How do you decide if something is worth building?

  Customer validation + personal conviction

• And how much time do you usually give an MVP before moving on?

  Tricky question, a year gives you enough time to see whether the core assumption holds up across different users, different use cases, and different market conditions. Less than that and you're often reacting to noise rather than signal. More than that without meaningful traction and you're usually solving a problem only you have.

I think founders often kill ideas too early. If even a few users clearly want it, I’d change the angle before I’d kill the product.

I built a reptile care app about as niche as it gets. The kill signal I use: if I can't find at least 3 people actively complaining about the problem online, the market is too small or too unbothered. The build signal: when people are already using messy workarounds like spreadsheets and notes apps to solve it themselves.

I’ve become much slower at falling in love with ideas.

A lot of things sound exciting in your head and feel completely unnecessary once they meet real users.

What I usually look for now:

• Is this a problem people already try to work around manually?

• Does someone feel this pain weekly, not yearly?

• Can I explain the value in one or two sentences without sounding clever?

I also pay attention to my own behavior while building. If I keep adding features before anyone cares about the core workflow, that’s usually a warning sign.

As for timing, I don’t think there’s a fixed MVP window. Some products die because nobody wants them. Others die because the team gives up before the problem is understood properly.

What I try to avoid is building in isolation for months. A small group of engaged users telling you “this solved something for me” matters more than vanity metrics early on.