What Real Users Made Me Simplify

There’s a strange thing that happens when real people start using something you built.

Before launch, complexity can feel like progress.

More settings.
More options.
More screens.
More flexibility.

Then someone actually tries to use the product.

And suddenly the most useful feedback isn’t:

“Can you add another feature?”

It’s:

“Why do I need to do this?”

That question can be brutal.

But it’s usually useful.

Users expose complexity you stopped noticing

When you build a product every day, you become familiar with it.

You know where everything is.

You understand why a button exists.

You know what happens after each step.

The user knows none of that.

They arrive with one goal.

And every unnecessary decision you make them take becomes friction.

A flow that feels obvious to you might feel confusing to someone seeing it for the first time.

That’s why I’m starting to think one of the most useful things early users give you isn’t feature ideas.

It’s permission to remove things.

Repetition matters more than one comment

One person getting confused doesn’t always mean the product is wrong.

But when the same thing happens repeatedly, it becomes difficult to ignore.

People skip the same step.

They fail at the same action.

They ignore the same option.

They ask the same question.

That repetition is a signal.

And often the answer isn’t adding another explanation.

It’s making the product simpler.

Simple doesn’t mean less capable

I used to think simplification meant removing value.

Now I think it often means making the value easier to reach.

There’s a difference between:

having more features

and

making the core job easier

Imagine a booking product.

Maybe it has:

• advanced analytics
• multiple staff roles
• loyalty points
• notifications
• custom settings
• several payment options

All useful things.

But if the actual booking flow takes eight confusing steps, none of that matters very much.

The user came to book something.

The core flow has to win first.

Real usage changes the roadmap

This is something I’ve been thinking about a lot while working around built.new.

I’m involved with the project, so obviously I’m close to the problem.

One thing I find interesting about AI-assisted product building is that adding things has become incredibly cheap.

Removing things is still a product decision.

AI can generate another screen in seconds.

But it can’t make an unnecessary screen valuable just because it was easy to build.

That’s why the loop after launch matters so much:

build → ship → observe → simplify → improve

The first version gives you a hypothesis.

Real users tell you where that hypothesis was wrong.

Maybe product progress should sometimes look smaller

We usually show progress by adding things.

New feature.

New integration.

New dashboard.

New workflow.

But some of the best product changes might look like:

• one less step
• one less decision
• one less setting
• one less screen
• one less explanation

The product becomes smaller.

But the experience becomes clearer.

And that can be a much bigger improvement than another feature release.

If you’ve shipped something before:

What did real users make you simplify?

Was it onboarding, navigation, pricing, a feature, or something you originally thought was essential?