Product thinking

TL;DR

I pushed to reframe "Shared Lists" as "Collaboration" because the original name narrowed the work to access control. The new frame made the team look at coordination, shared state, and the system people were actually trying to use.

Microsoft To Do: Naming shapes the product

Names aren't a finishing detail, they decide what kind of system a team thinks it's building.

The feature names we use in meetings set the boundaries for what we build. A narrow name leads to a narrow solution, a broader name can pull you into a bigger system and keep the team aligned on the actual user problem.

The name was already narrowing the work

At Microsoft To Do, we worked on a project called "Shared Lists", which sounded accurate because it technically was.

A list about to be shared.

But I soon realized that the name was limiting how we thought about the feature. It set the boundaries before we even got started.

Why "Shared Lists" was too small

Because we called it "Shared Lists", we solved exactly that by building permissions, invites, and access controls. We shipped… and it worked.

But it missed part of the user problem, because sharing implies a transaction. I give you access, and I'm done.

The missing system

Users weren't trying to "share" a list, they were trying to coordinate a household, plan a trip, or manage a project.

Collaboration requires ongoing interaction, and "sharing" captures the first second but misses the months or years of usage after that.

Changing the frame

I pushed to rename the domain to "Collaboration". It sounds like a subtle shift, but it changed the conversation and gave us permission to design the human side of the feature.

Too little, too late

By the time we saw the issue, the architecture for "Shared Lists" was already built. We had already shipped sharing, inviting, assigning, and attachments. But the underlying system wasn't ready for true ongoing collaboration.

Naming the technical implementation tends to ship the technical implementation. Naming the user goal at least gives the team a chance at the product underneath.

By the time the renaming happened, the cost was visible. Sharing was already shipped, the data model assumed access control as the primitive, and ongoing collaboration features, presence, comment threads, real-time updates, had to be retrofitted rather than designed in. The lesson wasn't that the rename was wrong, it was that the rename should have happened a quarter earlier, before the architecture set.

Why this changes the work

The words we use change what we think we're responsible for. If you name a project after a technical action, you will probably just build that action. If you name it after how people behave, you'll look for deeper ways to help them.

If we talk about "sharing", we focus on access. If we talk about "collaboration", we focus on how people actually work together. A small difference in wording changes the user experience.

Names shape architecture

The words we use can drive architecture. If we say "Sharing", the backend team might just build an access control list.

If we say "Collaboration", they probably will build a real-time sync engine.

Design is often making sure we're speaking the same language about the problem we're actually solving.

The same pattern showed up later when the team drove a new visual language for Microsoft To Do, closer to the original Wunderlist design. We didn't call it a redesign, we called it "To Do Evolution", or EVO for short. The wording moved the conversation from "replace what's there" to "respect what's there and make it better", and the design choices followed.

Closing

Names don't just describe scope, they create it.

Pick a small name, and you'll usually get a small feature. Pick a name that points at the real behavior, and you're much more likely to build the system people actually need.