The feature trap
Adding features feels like progress. Usually it just adds complexity. The products that win pick one job and do it well.
By Brian Rey · · build-for-the-job-not-features.md
"We need more features" sounds reasonable, but it often points in the wrong direction.
People use software to get a job done. Usually that means saving time or effort.
That's the idea behind Jobs to Be Done, a framework from Clayton Christensen. It changes the question from "what should we build" to "what is the user trying to get done."
A team doesn't buy project management software because they love organizing tasks. They buy it because deadlines slip and nobody knows what's going on.
The job is knowing what's happening before things fall apart. Once that's clear the roadmap gets simpler.
A feature is worth it when it makes that job faster or easier. If it doesn't, it's just more to build and maintain. And the product gets a little harder to use every time.
Jira kept expanding to cover more use cases. Simple things got slower. Linear picked a narrower job and kept it fast.
A lot of teams switched for exactly that reason.
Some features you need just to compete.
In 2026 AI is one of them in a lot of categories. Writing help in docs. Agents in developer tools. Those matter because they help with the core job.
Past that baseline, a feature only earns its place if it makes the job clearly easier.
Try this. Write the job your user hires you for in one sentence. Then go through your roadmap and ask if each item makes that job easier. If you can cut something and the job still gets done, cut it.