How I Decide Whether an Idea Should Become a Product

I start with the problem

The first filter is simple: can I describe the problem without describing the product?

If I cannot, the idea is usually still a feature, an aesthetic direction or a technology looking for a reason to exist.

A useful problem statement should describe a real friction someone experiences.

The stronger the friction, the less explanation the product needs.

I look for repeated need

One occurrence can be interesting. Repetition is more convincing.

Some of my product ideas come from tasks I keep doing manually. Others come from annoyances I notice while using existing tools. Sometimes the same request appears repeatedly in client or personal work.

Repeated friction is evidence that a small solution might have lasting value.

This does not mean the market must be enormous. A narrow problem can support a very useful product.

I try to shrink the first version

My instinct is often to imagine the complete product too early.

So I deliberately ask what the smallest version would be that still delivers the core value.

For a browser extension, that might be one reliable action instead of a dashboard full of features. For a web tool, it might be a focused workflow rather than a platform.

Smaller scope creates faster feedback.

It also makes abandonment cheaper if the idea turns out to be weak.

I check whether the advantage is meaningful

A product does not need to be completely original.

But it needs a reason for someone to choose it.

That reason can be better focus, better usability, a different audience, a clearer workflow, more privacy, less complexity or stronger integration with a specific use case.

If the only advantage is that I built my own version, that is not enough.

I consider maintenance before launch

The build is only the visible beginning.

Software creates future obligations: browser changes, operating system updates, bug reports, support, security concerns, store policies and dependency updates.

I try to estimate whether I am willing to own those obligations before I give the product a permanent public identity.

A small product with low maintenance can be more attractive than a more ambitious product that becomes a constant drain.

I ask whether it belongs in the ecosystem

Even a good idea may not belong in my current system.

I ask whether it strengthens an existing world, fills an obvious gap or teaches me something strategically useful.

If it creates a completely new audience, operational model and brand problem, the threshold should be higher.

Every new product increases the surface area of the ecosystem.

I separate experiments from commitments

One of the most useful distinctions is between building something and turning it into a product.

I can prototype an idea without naming it. I can test a workflow without publishing it. I can create an internal tool without promising support.

That freedom makes experimentation easier.

A product is a commitment. An experiment is a question.

The filter

Before I move an idea into serious development, I want strong answers to these questions:

1. Does it solve a real, understandable problem?
2. Does that problem repeat often enough to matter?
3. Can the first version be small?
4. Is there a meaningful reason to choose this solution?
5. Can I realistically maintain it?
6. Does it fit the direction of the larger ecosystem?

Not every answer has to be perfect.

But if most of them are weak, the idea probably deserves to remain an idea.