When I Build Products, the First Thing I Cut Isn't Features—It's Illusions

In the past, when building products, my most natural instinct was to list features first.

Whenever I thought of a direction, I would quickly start thinking: how to design the pages, how to fill in the flows, whether to build the backend first, whether to reserve permissions in advance, and whether to set up data tracking. I always felt that as long as the features were more complete, the product would look more like a product, and success would be closer.

But in the past two years, I've increasingly felt that this isn't the case.

Many products don't die from insufficient features, but from too many illusions.

Now, when I build products, the first thing I cut is often not a specific feature, but the unverified things in my mind that I've already taken for granted.

For example, I used to easily assume:

• Users really have this problem.
• Users will be willing to switch from their current approach.
• As long as I build it, they will come and use it.
• Once people start using it, there will naturally be opportunities to charge later.
• If this feature isn't built now, the product won't be complete.

Looking back now, many of these are not facts, but just my own illusions.

And the most troublesome part is that you can see features, but you can't see illusions.

So in the early stages of a product, a common state emerges: people are busy, and the product seems to be progressing, but in reality, it hasn't moved forward much.

Pages are being built, APIs are being written, flows are being filled in. You're fully engaged every day, and you have a feeling of "I'm seriously working on this."

But I've gradually realized that often what's being advanced is just development, not the product.

Features solve "how to do it," not "whether it should be done."

If the direction is wrong, the more features you add, the worse it gets.

If the core assumption doesn't hold, the faster you develop, the faster you deepen the mistake.

I've become increasingly wary of one thing:

Some features aren't solving problems; they're protecting my illusions.

I really believe this now.

For example, before even figuring out whether users will actually use it, you start thinking about how to design the backend;

Before validating the core value, you start adding permissions, configurations, logs, and notifications;

Before understanding why users would stay, you plan payments, memberships, and data dashboards.

On the surface, this makes the product more complete, but in reality, it's often just giving yourself the comfort that "I'm doing this seriously."

But being serious doesn't equal being effective.

Being complete doesn't equal being validated.

Over the years, I've developed a few more specific insights about "illusions."

Illusion 1: I think users have a need

This is the most common.

Often, we don't see a real need, but a "logically plausible problem."

You think it's reasonable, the flow makes sense, and you can even imagine how users would use it.

But the problem is, being reasonable doesn't equal being real.

What you find troublesome might not be painful for others.

What you think should be solved might already be something people are used to.

What you see as an opportunity might just be something you personally care about.

When building products, it's easy to overestimate not only your execution ability but also your understanding of needs.

Illusion 2: I think users will change their habits

Even if you do find a real problem, it doesn't mean users will change their current behavior because of your product.

I feel this strongly now.

A product doesn't just compete with the "problem"; it also competes with "users' existing habits."

After building a solution, developers might think it's more advanced, elegant, and efficient, but users may not buy it. The reason is simple: their original way, though clumsy, is familiar.

And changing habits is itself a cost.

So it's not that if you make a better product, users will definitely switch. Often, you're not competing in a blank market; you're competing with WeChat, Excel, Feishu, manual processes, veteran employees' experience, and even the attitude of "let's make do for now."

Illusion 3: I think the more complete the features, the easier the success

I easily fall into this trap myself.

Because features are the easiest thing to give you a sense of control.

Build a page, you can see it.

Add a flow, you can see it.

Add a configuration item, you can see it.

People naturally mistake "more features" for "closer to success."

But in the early stages, many features don't increase the success rate; they delay validation.

You think you're improving the product, but you might just be avoiding a harder question:

Does anyone actually care about this?

Sometimes, adding features isn't for users; it's to make yourself feel more at ease.

Because if you stop adding, you have to face the question: is the direction even valid?

This question is much harder to face than writing code.

Illusion 4: I think usefulness equals willingness to pay

This is also easy to misjudge.

There's a big gap between something being "useful" and it being "worth paying for."

Users might find it somewhat useful, but that doesn't mean they'll pay.

Users might say it's good, but that doesn't mean they'll keep using it.

Users might be willing to try it, but that doesn't mean they'll form a purchasing habit.

What really determines payment are often more practical factors:

• How painful is the problem?
• How clear is the benefit after solving it?
• How high is the usage frequency?
• Are there cheap or free alternatives?
• Is the user at a stage where they're willing to pay for this?

So "someone says it's good" isn't validation; at best, it's a signal.

What's closer to validation is willingness to keep using, or even willingness to pay.

Illusion 5: I think I'm building a product, but I'm actually just self-indulging

This one is a bit harsh to say, but it's very real.

Sometimes we're not building a product, but something we think is cool.

Sometimes we're not solving a problem, but satisfying our own imagination of "building a complete product."

Sometimes we frantically add features, not because users need them, but because we can't stand the product not looking good enough.

In such moments, people are especially busy and especially invested.

But the deeper the investment, the harder it is to stop.

Because once you stop, you have to admit: maybe it's not that the features aren't enough, but that the direction itself isn't valid.

This cost isn't just time; it's also psychological.

So now, when I build products, I deliberately cut these illusions first.

I often ask myself a few questions, and I rely more and more on them to decide whether to continue and whether to add more.

1. Does this problem really exist?

Not whether I think it exists, but whether real people have repeatedly mentioned it, complained about it, or can't avoid it.

2. Is this problem painful enough?

Not "a bit troublesome," but "uncomfortable if not solved."

3. How do users solve it now?

If they already have alternatives, then I'm not facing a blank opportunity, but a scenario already occupied by habits.

4. Is the feature I want to build now the smallest validation path?

Is it validating the core value, or just making the product look more complete?

5. If I don't do this now, will the product die?

If not, then it's probably not what should be done right now.

I increasingly feel that the most expensive thing in product development isn't writing a few more pages or doing a few more reworks.

The most expensive thing is carrying a bunch of unverified illusions, continuously investing time, attention, and development costs, and then deepening a direction that was never valid in the first place.

Features can be added later.

Interfaces can be changed later.

Flows can be smoothed out later.

But illusions, the later you cut them, the greater the cost.

So now, when I build products, I rarely start by asking:

Should this feature be added?

I more often ask:

Am I validating right now, or am I comforting myself?

These two questions look similar.

But the results they produce are vastly different.