5 Things I Consider When Deciding Whether a Feature Is Worth Building

Now when I work on products, I increasingly ask fewer questions like:

"Can this feature be built?"

More often, I ask:

"Is this feature worth building right now?"

These two questions look similar, but the outcomes differ greatly.

Because "can it be built" discusses implementation, while "is it worth building" discusses judgment.

The former usually leads you into technical details. The latter forces you to return to the product itself: Is this thing truly necessary? Is now the right time? Will it actually bring results after being built?

I increasingly feel that many products don't die because they can't be built, but because they build too many things that shouldn't have been built first.

Features, one by one, don't seem significant; requirements, one by one, sound reasonable. When building them, you often think, "Adding this will make it more complete."

But in the end, the most problematic thing is precisely the accumulation of these "seemingly doable" requirements.

Because a product is not built by piling up features. Truly good products, more often than not, succeed not because they do more, but because they filter precisely.

So now, when I judge whether a feature is worth building, I mainly look at the following five things.

1. Does this problem truly exist, or is it just something I think should exist?

This is the first layer of judgment, and often the most important.

Many features seem "reasonable" because they make logical sense. The process can be explained, the scenario can be imagined, and at first glance, it looks plausible.

But being logically valid is not the same as being valid in reality.

Now I pay more attention to:

• Have real people repeatedly raised this issue?
• Does this issue frequently appear in real workflows?
• Is it a long-standing friction point or occasional complaints?
• Is it a personal preference of a few, or a genuine need with some commonality?

Because many times, the need isn't fake, but its "necessity" is overestimated.

You might think it's important, but users may not. You might think it should be done sooner or later, but in reality, it might not be the right time now.

So now I don't decide to build something just because "it sounds right." I first check: Is it a real problem, or just my imagination?

2. Is this problem painful enough?

Having a need and having a strong need are not the same thing.

Many things, users will naturally say, "It would be better if it existed." But "better" needs are often not the most worthwhile to build at the moment.

Because product resources are always limited. Especially when working alone, time, attention, and development costs are very expensive.

So now I care a lot about this question:

If this problem isn't solved, how much does it actually hurt the user?

I tend to lean toward building things that:

• If not solved, will continuously block the process.
• If not solved, will significantly increase costs.
• If not solved, will cause people to abandon usage.
• If not solved, will prevent goals from advancing.

Rather than needs like "it would improve the experience a bit."

It's not that the latter isn't important, but the order matters.

In the early stages of a product, the biggest fear isn't lack of detail, but treating many "can be done later" things as "must be done now."

Truly painful needs usually force users to find workarounds themselves. Less painful needs, users might mention verbally, but it doesn't stop them from continuing to make do.

These two types of needs cannot have the same priority.

3. Does this feature drive results, or is it just filling a sense of completeness?

I'm particularly wary of one type of feature:

It seems correct and is indeed useful, but its real purpose is more about making the product "look more complete."

I easily fall into this trap myself.

Because once you start building a product, you naturally want to make things look decent. Should the backend be more complete? Should configurations be more detailed? Should permissions be more comprehensive? Should data be richer? Should the process be smoother?

These things all have value. But the problem is that they often don't directly drive the most critical current results.

For example:

• It doesn't help you validate the need faster.
• It doesn't significantly improve retention.
• It doesn't bring in payments faster.
• It doesn't determine whether users will continue using it.

It's more about filling a "sense of completeness."

And this sense of completeness can be addictive. Because it creates a strong feeling of progress:

I'm doing things, I'm improving the product, I'm making the system more professional.

But many times, this feeling of progress only reassures yourself, not necessarily advancing results.

So now when I look at a feature, I ask:

Is it driving results, or just filling a sense of completeness?

If it's only the latter, I'm usually more cautious.

4. Is now the right time to build this feature?

Some features aren't wrong, but the timing is wrong.

This judgment is important.

Because many product problems aren't about the feature itself being wrong, but about the stage being wrong.

For example:

• During the validation phase, you start adding complex configurations.
• Before users have stably stayed, you build heavy backend systems.
• Before the payment path is figured out, you spend a lot of time on edge-case optimizations.
• Before the core flow is settled, you start building extensive expansion capabilities.

These features might all need to be built later. But "need to be built later" doesn't equal "should be built now."

I increasingly care about:

Does this feature align with the main goal of the current stage?

If the current stage's most important thing is validation, then features should serve validation.

If the current stage's most important thing is delivery, then features should serve delivery.

If the current stage's most important thing is stability, then features should serve stability.

Many times, it's not a question of whether the feature is worth building, but whether building it now will disrupt the current rhythm.

Once the sense of stage is disrupted, the whole product can easily become scattered.

5. After this feature is built, will it bring verifiable changes?

This is something I value highly now.

Because some features, after being built, are hard to judge whether they have value. You build it, the product looks more "proper," everyone thinks it's good, but in the end, it's hard to say what changes it brought.

Now I tend to prioritize features that:

• After building, you can see changes in user behavior.
• After building, you can validate a key assumption.
• After building, you can significantly reduce a certain friction.
• After building, you can quickly judge whether the direction is viable.

In other words, I prefer to build features where "after building, you can know if it was worth it."

Because in the early stages of a product, the most precious thing isn't the number of features, but the speed of cognitive updates.

The faster you know what's right and what's wrong, the better the product's chances of survival.

Conversely, features that are hard to verify value after building, I'm now more cautious about. Because they easily consume time but don't give you new judgment criteria.

So now when I judge a feature, the core isn't "do I want to build it," but "should it be built now."

If I compress the above into one sentence, it's roughly:

Now when I look at a feature, I don't first ask if it makes sense, but whether it's the most worthwhile thing to do right now.

Specifically, I mainly look at these five things:

1. Does this problem truly exist?
2. Is this problem painful enough?
3. Does this feature drive results, or is it just filling a sense of completeness?
4. Is now the right time to build this feature?
5. After this feature is built, can it bring verifiable changes?

These five criteria won't make me right every time. But at least they help me avoid building many things that "seem reasonable but have little meaning after completion."

I increasingly feel that the hardest part of product work isn't thinking of features, but daring not to build features that shouldn't be built yet.

Because many features can be built, but not many are worth building right now.

So now when I see a new feature, I don't directly jump into "how to implement" mode.

Instead, I pause and ask myself:

Is this feature the most worthwhile thing to do right now?

Many times, what truly sets people apart isn't speed of execution, but precision of filtering.