The Feature Trap

"We need more features" sounds reasonable, but it often points in the wrong direction.

People use software to get a job done. At a basic level, software is a tool to save time, reduce effort, or make things more predictable.

This is the idea behind Jobs to Be Done, a framework by Clayton Christensen, and it shifts the question from "what should we build" to "what is the user trying to accomplish."

A team doesn't adopt project management software because they enjoy organizing tasks. They use it because deadlines are missed, communication breaks down, and nobody knows what's happening.

The job is having the right information at the right time so work doesn't fall apart, and once that job is clear, the roadmap gets simpler.

A feature matters when it helps the user move faster, decide better, or do less to get the same result. If it doesn't, it adds complexity without real value, and complexity has a cost: more to build, more to maintain, and a product that gets harder to use over time.

Jira expanded to cover many use cases, and simple workflows became slower as a result. Linear focuses on a narrower job, while creating, updating, and tracking work stays fast and AI-native.

As a result, many teams switched because Linear got the job done in a much simpler way.

Although focus is an advantage, some features are required just to compete.

In 2026, AI is part of that baseline in many categories, writing help in docs, AI Agents in developer tools. These matter because they directly support the core job.

Beyond that, adding more only helps if it makes the job meaningfully easier.

Write the job your user is hiring you to do in one sentence, then go through your roadmap and ask if each item makes that job easier or more reliable. If you can remove something and the job still gets done, it's probably not essential.

Your roadmap is defined by what you choose not to build.