Every PM tool ships with a settings page. Workflow templates, field types, automation rules, notification preferences, role permissions, display options. It's the first thing teams configure and the last thing they enjoy.
We killed ours. Not trimmed it down — removed it entirely. Here's why.
Settings pages are apologies
A settings page is the product admitting it doesn't know what you need. “We couldn't decide, so you decide.” That sounds respectful. In practice, it means every team burns an afternoon arguing about whether “In Review” should come before or after “QA” — before anyone has done a minute of real work.
The setup tax is real. We talked to teams that spent longer configuring their PM tool than they spent using it. Some never got past configuration. The board was pristine, empty, and abandoned by week two.
Configuration creates false confidence
There's a psychological trap in configuration: it feels productive. You're customizing! You're tailoring the tool to your exact workflow! But you're actually doing two things wrong at once. First, you're spending time on meta-work instead of work. Second, you're encoding assumptions about a workflow that hasn't started yet.
By sprint 3, half those configuration choices are wrong. The column names don't match how work actually flows. The custom fields nobody fills in. The automation rules that fire at the wrong time. But nobody goes back and fixes the settings — they just work around them.
The conversation is the configuration
When you tell Lova “We need to ship a new auth flow with OAuth, session management, and a login page,” it creates columns and tasks from that description. Not from a template. Not from a settings panel. From what you actually said you need.
If the structure is wrong, you don't open settings — you say “actually, let's split the auth work into frontend and backend tracks.” Lova restructures the board. The conversation is the configuration layer. It's faster than any settings page because it's the interface you were going to use anyway.
Defaults should be invisible
Good defaults aren't a fallback — they're the product. Every PM tool has defaults, but they treat them as starting points for customization. We treat them as the answer. Three columns. Simple statuses. No workflow engine. No custom fields.
This sounds limiting. It's the opposite. When there are no settings to argue about, teams start working immediately. When the structure comes from conversation, it matches reality instead of a template someone picked six months ago.
What about power users?
The honest answer: we don't optimize for power users yet. Power users are the 23% who already use PM tools. They want custom fields, complex automations, and Gantt charts. They're well-served by Linear, Jira, and Asana.
We're building for the 77% who don't use PM software at all — not because they're unsophisticated, but because every tool asked them to become a PM tool administrator before they could manage a project. The settings page was the barrier. We removed the barrier.
Will we eventually need some configuration? Probably. But we'll add it in the conversation, not behind a gear icon. “Set up a weekly standup every Monday” is better than finding the automation tab, creating a rule, picking a trigger, and configuring a schedule. Same outcome, zero settings.