Product thinking

Naming shapes the product

Naming isn't just labeling. It's the first product decision you make.

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

Context

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

The new user onboarding flow, designed to feel lightweight despite multiple decision points.

A list about to be shared.

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

The trap of "Shared Lists"

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

But it failed the user. 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.

That requires a system of ongoing interaction. "Sharing" captures the first second, but misses the next three months, or years of usage.

Reframing to "Collaboration"

I pushed to rename the domain to "Collaboration". It sounds like a subtle shift, but it changed the conversation entirely.

The name gave us permission to build the human side of the feature.

Too little, too late

We realized this too late. The architecture for "Shared Lists" was already built. We shipped the features. Sharing, inviting, assigning, attachments,but the underlying system wasn't ready for true, ongoing collaboration.

The lesson stuck: If you name the technical implementation, you get the technical implementation. If you name the user goal, you get a product.

Language as a pattern, not a one-off

This happened again later. When the design team was driving an entirely new visual language for Microsoft To Do (which was closer to the original Wunderlist design), we were very careful about what we called the project.

We didn't call it a redesign. We called it "To Do Evolution", or EVO for short. That name changed everything.

Taking deep care, not redesigning

"Redesign" implies vanity, change for the sake of change. "Evolution" implies respecting what exists while making it better.

This simple word choice killed ego-driven ideas, and focused the team on continuity.

Why this matters

The words we use change what we think we're responsible for. If you name a project after a technical action, you'll probably just build that action.

But 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. That simple difference changes the user experience.

Strategy is wording

Words 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 just ensuring we're all speaking the same language about the problem we're actually solving.

Closing

A name defines your product, and its features.

Pick a small name, and you'll get a small feature. Pick a strategic name, and you might build a business, or collaborate on someone else's for that matter.