The best products are often the ones you don't see

I frequently work with product teams or applications where I struggle to get a clear answer to a simple question: why does this need to be a product or a feature at all?

Too often, products start at the wrong level. They begin with the largest possible scope: first provide insights, then provide overview, and only then—maybe—add something actionable while the users are most served by actions.

On top of that, many products fall into the rebuild pitfall: re-creating existing processes (often outdated) exactly as they already work, just wrapped in new software. And often, there’s the assumption that every product needs its own interface, its own UI, its own place the user now has to go.

This results in: more tools, more dashboards, more cognitive load and most important: more distraction.

The insights fallacy

Imagine a tool for mechanics who work all over the country. The product is presented and the first thing you see is a map with all the locations that need a visit.

It is said to “provide insights”. But insights for who, exactly? These users don’t wake up wanting insights. They want to get their jobs done.

Another example: a tool for the financial department. There’s a dashboard. Of course there is. Showing all the information and overview there is. But the work people need to do is never on the dashboard.

For them, it’s just another thing they need to use. Another tab. Another login. Another system that competes for attention.

In general people want to:

• visit/call the right customer
• follow up on the right issue
• focus on conversations that matter
• spend less time figuring out what to do next

Help people do the work

Mechanics already use their phones. Why not just send them the coordinates relevant for this day through a channel they already use, so they can open navigation with one tap?

Why not send a simple list: “Here are the top 5 things you need to do today.” Why not answer the real question: Which customers need attention today?

That’s the job. Not the map. Not the dashboard. Not the interface.

The timesheet example

I recently had to use a brand new timesheet tool. It is incredibly badly built. Full of flaws and errors. Imagine messing up pure CRUD application…in 2026! Beyond the lack of quality, the bigger question is: why does this exist as a separate app at all?

Why do I need another tool? Why is my cognitive load increased for something this trivial?

Why can’t I just email my hours? Or send them via Teams? Or reply to a message every Friday with “x hours”?

The system could still validate, process, and store everything in the background. I don’t need to know about that. I need to focus on my job to be done.

Invisible functionality

In all these examples, the functionality could have been invisible. Highly efficient, reliable but invisible to me as a user. Ideally, I wouldn’t even know there is a tool.

I understand why visible functionality is tempting. It’s easier to explain. Easier to demo. Easier to sell internally. A dashboard or a map is more “sexy” than a backend system that quietly sends the right message at the right time. But that’s often not where the real value is. Personally, I’ll choose boring and effective over sexy and distracting 10 times out of 10.

Jobs to be done

What really makes the difference is always start with the user’s job to be done.

• What is the user actually trying to achieve?
• What steps do they currently go through to get there?
• Which of those steps are truly necessary, and which are just “the way we work”?

When you look at it this way, you’ll often find that the most valuable improvements come from removing steps, not adding features.

Make it magical (quietly)

Good products surprise users by giving them the right information, at the right time, in the right place. Not by pulling them into yet another UI, but by fitting naturally into how they already work. So instead of starting with product design that assumes a new interface, start by identifying what jobs need to be done. If the best experience means the product fades into the background than the product is doing its job.