The Product, the User, and the Decisions Between Them

Should a product give you a clear, opinionated way of doing things, so you don’t have to think too much about the process? Or should it give you enough flexibility to shape the product around the way you already work?

I recently explored two products that sit on very different ends of that spectrum: Linear and ClickUp. I wasn’t trying to figure out which one was better. In fact, I think both products are good at what they are trying to be.

What I wanted to understand was the trade-off between being opinionated and giving users the freedom to create their own workflow.

As designers, it’s easy to spend a lot of time looking at interfaces. We notice the layout, the interactions, the visual details, the things we like, and the things we would probably do differently. But I wanted to go a little deeper.

I wanted to understand what makes these products work beyond what I can see on the surface. Not just what they built, but how the product actually behaves when you use it to accomplish something.

I gave myself a simple scenario:

I’m a product design engineer at a small startup. The team wants to improve the checkout experience because too many users are abandoning their purchases. I need to organize the work required to investigate the problem, design a solution, build it, and eventually launch it.

Nothing particularly complicated. I just wanted to see what the experience would be like using both products. I deliberately kept the exercise narrow. Rather than trying to understand everything both products could do, I focused on one basic question:

What happens when I have work that needs to be organized and managed?

I started with Linear.

Linear: “We’ve already thought about this for you”

My first experience with Linear was interesting because I didn’t have to think too much about how the system should work. There was already a structure.

I had a workspace. Within that, I could create a team. Within the team, there were projects, issues, cycles, milestones, and other concepts that already had a relationship with one another. I didn’t have to ask:

What should my workflow look like?

I started by creating a team, then a project. Then I came across milestones and issues. The more I interacted with the product, the more I started to understand the model it was giving me. A project could contain milestones. Milestones could break the work into meaningful chunks. Issues represented the individual pieces of work.

It wasn’t asking me to figure out my own system before I could start. It had already given me one.

This meant I had to spend some time understanding Linear’s mental model, but once I understood it, I could mostly just operate within it and I think that’s the real value of an opinionated product. It doesn’t necessarily eliminate learning. It eliminates decision-making.

Instead of giving me ten ways to structure my work and asking me to choose, it gave me a model and said:

“This is how we’ve designed this system to work.”

For someone whose work fits that model, that’s incredibly powerful. There were other scenarios where this opinionated approach played out.

First, when I created an issue in a milestone, Linear didn’t overwhelm me with older issues from other milestones, making it difficult to find the new one. Instead, It presented the one I had just created and progressively revealed others when I needed them.

The display properties of an issue also followed this philosophy. Initially, I thought Linear wasn’t giving me enough information about an issue’s milestone. Later, I discovered that the milestone simply wasn’t part of my default display properties, and I could choose to reveal it when I needed it. That felt like a good balance.

Opinionated by default, flexible when necessary.

Another scenario was with the AI agent feature, where an issue could become more than a record of work. I could copy the context of the piece of work (issue) as a prompt for any AI coding agent I had configured.

That felt particularly thoughtful and very familiar to my present workflow because the product wasn’t treating planning and building as completely separate activities. It was creating a bridge between them, reducing the distance between intent and execution.

This showed that Linear had an opinion about how I should work and how things connect. And in this case, I liked that opinion.

Unfortunately, opinion sometimes comes with a cost.

There was one decision Linear made that I questioned: the default status of a newly created project and issue being Backlog.

It isn’t necessarily wrong. In fact, I can understand the logic. Creating a piece of work doesn’t necessarily mean the team has committed to doing it immediately. But from my perspective as a designer creating something I intend to work on, I naturally think:

Create → To Do → Work.

Linear’s model is closer to:

Create → Backlog → Decide → To Do → Work.

Neither is objectively wrong. They simply represent two different assumptions about what “creating work” means.

Creating a piece of work doesn’t necessarily mean committing to work on it now. A product manager might create dozens of issues during planning. Automatically putting all of them into active work would create a different kind of mess.

And that’s where I started to understand something important:

An opinionated product is always making assumptions about you. When those assumptions match the way you work, they feel like guidance. When they don’t, they feel like constraints.

ClickUp: “You get to make your own choices”

ClickUp gave me almost the opposite feeling. I ran through essentially the same scenario, and the experience felt very different.

ClickUp gave me a lot of power. I could define my workspace structure. I could choose what I was using it for. I could configure workflows, statuses, views, and other parts of the system. I could decide how I wanted my work to look.

And at first, that felt empowering.

Then I realized something:

I had to make a lot of decisions before I could actually get to the work.

I had to start by creating a Space, where I had to define a number of things:

• The structure I wanted
• The kind of views I wanted my work presented in
• The type of task statuses I wanted
• Additional ClickApps I’d like to activate
• Where this task belongs
• How should I organize this?

The product was giving me the tools to create my own system, but that also meant I had to become responsible for creating the system.

And I think that’s the hidden cost of flexibility. More control doesn’t always mean less friction. Sometimes, it simply moves the friction from using the product to configuring the product. However, flexibility has a very real advantage.

The interesting thing is that I also found myself appreciating ClickUp’s flexibility. For example, I loved the ability to duplicate a task and carry its structure into another piece of work. I also liked being able to define the multiple ways I wanted to view the same body of work.

• Kanban
• Timeline
• Workload
• And a lot more

Different views answered different questions.

And this is where I wouldn’t want to make the mistake of saying: “Linear is simpler, therefore Linear is better.” That’s not necessarily true. Imagine a team with a very specific workflow that doesn’t fit Linear’s assumptions. Maybe they have:

Marketing → Design → Legal → Engineering → Finance → GTM teams

For that organization, being told, “Here’s the workflow. Just use it,” might be more frustrating than helpful.

ClickUp’s flexibility could be exactly what they need. The ability to create your own workflow isn’t unnecessary power if your workflow genuinely needs to be different.

So which approach is better?

I don’t think the answer is opinionated products or flexible products. I think the better question is:

Which decisions should belong to the product, and which decisions should belong to the user?

Some decisions are just cognitive overhead. If most users don’t have a reason to make a particular decision, the product should probably make it for them. Give me a sensible default. Give me a clear path. Let me get to the outcome without asking me to design the system first.

However, there are other decisions that are meaningful. If teams genuinely work differently, forcing everyone into the same structure can become a limitation. That’s where flexibility becomes valuable.

The goal shouldn’t be to give users maximum choice, it should be to give them meaningful choice.

What’s the real cost of choice?

This is probably the biggest thing I took away from comparing Linear and ClickUp.

We often talk about flexibility as if it is automatically a feature. But every additional choice comes with a cost.

More options can mean:

• More control
• More personalization
• More use cases supported

But they can also mean:

• More decisions
• More configuration
• More cognitive load
• More inconsistencies

And the reverse is also true. Constraints can mean:

• Faster decisions
• Less cognitive load
• A clearer mental model
• More consistency

But they can also mean:

• Less flexibility
• More adaptation
• Frustration when the model doesn’t fit

So for me, the sweet spot isn’t maximum flexibility or maximum opinionation.

It’s something closer to:

• Opinionated enough to guide me.
• Flexible enough to accommodate me.

Give me a good default. Let me get started without having to configure everything. And then, when I have a real reason to work differently, give me the ability to go deeper.

What I think…

If you’re designing for a relatively specific audience with a reasonably predictable workflow, I’d lean towards being more opinionated. Don’t make users configure things they don’t need to configure. Give them a strong starting point. Make the common path feel almost obvious.

But if you’re designing a platform for teams with fundamentally different ways of working, flexibility becomes much more important.

The trick is making that flexibility progressive rather than mandatory.

Because ultimately, good product design isn’t about giving users more control or less control. It’s about knowing which decisions users should have to make in the first place.

The Product, the User, and the Decisions Between Them was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.