Why we removed half the settings

As our product grew, the interface became more flexible. More toggles, more customization, more ways to configure workflows for different teams.

At first, this felt like progress. Users were asking for control, and we kept adding it.

Over time, though, something started to change. New users took longer to get started, onboarding became harder to explain, and simple workflows began feeling heavier than they should have.

The product was becoming more powerful, but less intuitive.

More flexibility created more hesitation

Many users never changed the default configuration, but they still had to process every available option before moving forward.

That small amount of friction repeated constantly throughout the product:

• choosing between views

• configuring workflows

• adjusting preferences

• deciding how things should behave

None of these actions were difficult individually, but together they slowed the experience down.

Most teams wanted clarity, not customization

After reviewing usage patterns, we noticed something surprisingly consistent. The majority of teams were converging toward similar workflows regardless of how much customization was available.

The extra flexibility mainly increased complexity around the edges.

This changed how we thought about product design. Instead of asking how many options we could support, we started asking which decisions the product should make automatically.

Comparing the experience

The difference became obvious once we simplified the interface

The product didn’t become less capable. It became easier to operate.

Strong defaults improved confidence

One of the biggest changes was psychological. Users stopped second-guessing the system as often.

Instead of spending time configuring behavior, they trusted the product to make reasonable assumptions by default. That trust reduced hesitation and helped workflows feel faster overall.

This also made collaboration easier because teams were no longer working inside heavily customized setups that behaved differently for everyone.

A small example

We also simplified how project summaries were generated internally.

async function createProjectSummary(updates: Update[]) {
  return ai.generate({
    input: updates,
    format: "brief",
    sections: [
      "key progress",
      "active blockers",
      "next priorities"
    ]
  })
}

async function createProjectSummary(updates: Update[]) {
  return ai.generate({
    input: updates,
    format: "brief",
    sections: [
      "key progress",
      "active blockers",
      "next priorities"
    ]
  })
}

async function createProjectSummary(updates: Update[]) {
  return ai.generate({
    input: updates,
    format: "brief",
    sections: [
      "key progress",
      "active blockers",
      "next priorities"
    ]
  })
}

async function createProjectSummary(updates: Update[]) {
  return ai.generate({
    input: updates,
    format: "brief",
    sections: [
      "key progress",
      "active blockers",
      "next priorities"
    ]
  })
}

Previously, users could customize output structure extensively. In practice, most teams preferred a consistent format that was easier to scan and share.

Simplicity scales better

As products grow, complexity accumulates gradually. Each additional setting feels small on its own, but together they shape how heavy the product feels over time.

Removing options forced us to focus more carefully on defaults, structure, and workflow clarity

Good product design often means removing decisions instead of adding flexibility.

That idea became more important to us as the product matured.

The product feels calmer now

The biggest change wasn’t measurable through a single metric. The product simply feels easier to move through.

New users understand it faster. Teams spend less time configuring workflows. Everyday interactions require less interpretation.

In many ways, removing functionality improved the experience more than adding new features ever did.