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

Usually makers fail, because they are makers. To create a product, and before any kind of making, a good analysis needs to be done. Do a S.W.O.T analysis. Find your audience, talk with, check their problems their needs, and behavior. Check the market cap, to see if all this makes sense. Do a kind of small requirement document, do an MVP, discuss it with the audience. And this may take months.

Once all is clear, and there are good indications and positive feedback, then the maker can start gradually to prepare more detailed requirements, (functional, non-functional), UI/UX, architecture, backlog, etc. And all the time, communication with the potential clients.

And my question is, how many people are actually following those steps, before pushing their products in platforms like this? ;)

They don't teach us such things at technical universities ;)

And we are still far way from the sales and marketing strategies. Even though the clients should be known, selling the products is mostly difficult for makers, like me ;)

Nika, hi!

Thank you so much for mentioning @ProblemHunt — I really appreciate it!

To answer your questions, personally, this is how I would do it:

1. First, figure out whether people actually have the problem. To do this, you need to talk to people using questions related to their past and present experiences (people often lie about the future).

2. If the problem exists, and most importantly we see that it is truly painful, then we move on to building an MVP.

3. We give the MVP to users, collect feedback, and continue improving the product until the people’s problem is solved (this will become obvious).

This whole process can take different amounts of time — it all depends on the complexity of the problem and the product. In one case it may take 2–3 months, while in another it could take 1–2 years. 😊

Most ideas don’t fail because they’re bad — they fail because no one cared enough.

So the first filter for me isn’t “is this big?” but “is this actually felt by someone?” If I can’t point to a real, recurring frustration (ideally one I’ve experienced myself or seen up close), I don’t touch it. Validation tools like are useful, but they’re signals — not decisions. You still need judgment. If something feels unoriginal but solves a real pain better, faster, or more honestly, it’s still worth building.

Dropping an idea usually comes down to energy, not just metrics. If after a fair push (talking to users, iterating, trying to get even a small group to care) there’s no pull and you find yourself losing conviction, that’s a red flag. But lack of traction early on doesn’t automatically mean failure — it often just means distribution isn’t solved yet. A lot of good products don't reach success because the founder expected immediate validation instead of building endurance.

For MVP timelines, I don’t believe in rigid deadlines. I look for movement: are people returning, asking for more, even in small numbers? If yes, I keep going. If not, I ask a harder question — do I still believe in this enough to push through the quiet phase? Because if you truly do, you don’t abandon it easily.

Sometimes ideas don’t need to be dropped — they need time, better positioning, or eventually more resources than a solo founder can provide.

The question I come back to—and one I think every founder should ask—is this: are you simply trying to validate that something could work, or are you genuinely committed to doing what it takes to make it work?

I don't usually kill ideas if I believe they make sense. I adjust how I build them.

Most of my pivots weren't about the idea being wrong — they were about the timing, the form, or the approach. The core stayed. What changed was how I got there.

The harder question for me isn't "should I kill this?" but "why isn't this working yet?"

Sometimes the answer is the audience. Sometimes it's the timing. Sometimes it's just the way the idea is being translated into a product.

The ProblemHunt and 404tomb references are great resources. Most of us skip that step entirely.

My personal filter came down to one question, which was is there a painful workaround that people are already doing on their own? If someone is copying and pasting raw documents into ChatGPT and asking it to summarise them, that's a real signal. They've already decided the problem is worth solving. You're just building a better version of what they've already hacked together.

The MVP timeline question is harder - I've found the wrong metric is how long you've been building, and the right one is how many people you've watched use it without you explaining it first. If you have to pitch it every single time, that's the clock to watch, not the calendar.

What made you look at ProblemHunt specifically? Curious whether you found it genuinely useful for killing ideas or mostly for validating ones you already wanted to build.

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)

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