The first time I led a team with full commitment to building something people actually wanted, I learned that the most important user in the room was me. And then my teammates. And then, eventually, everyone else.
The Team Becomes the User
There's a version of product development where you start with a market. You study it, segment it, define a persona, and build toward it. It's rigorous and defensible and produces a lot of Notion docs. It also keeps you at arm's length from the thing you're making.
When I led my first real team, we didn't have the luxury of that distance. We had a problem we had all experienced personally — something missing from our own lives that we were convinced was missing from other people's lives too. So we started there. We started with ourselves.
I was user #1. My teammates were users #2 through 5. We built what we would want to use. We argued about it the way people argue about things that actually matter to them. What should this feel like? What would make us open this every day? If we were a stranger who had never heard of us, what would make us stay?
The rule we set early — and held to — was that there were no wrong ideas in that first phase. Not because every idea is good. Most ideas are not good. But because the instinct to protect the product from bad ideas too early is the same instinct that protects it from surprising ones. You need the mess first. You can clean it up later.
Build Fast, Then Feel It
We moved quickly. Uncomfortably quickly, by most standards. A feature would get sketched out in the morning and be in the hands of the team that evening. Not polished — functional. Barely finished. The kind of thing you'd be embarrassed to show a user.
That was the point. The goal wasn't to make something impressive. The goal was to make something real enough to have an opinion about. You can't react to a mockup the way you react to a thing you're actually using. The mockup doesn't fight back. It doesn't surprise you. It doesn't reveal the gap between what you thought you wanted and what you actually wanted.
The aha moment — and there was a specific one, a day I remember clearly — came when we were using an early version of the product as part of our actual routine, not as a test. Someone said something in passing, a small observation about how natural a particular interaction felt. It wasn't a feature we had debated. It was a consequence of a simpler decision we'd made for different reasons. That moment of unplanned rightness, the thing that just worked without being engineered to work, was the first time I understood what delight actually is. It's not designed in. It's what survives the editing process.
Failure Is the Pace, Not the Exception
We failed constantly. Features that seemed obvious fell flat. Flows we'd argued were intuitive confused everyone who hadn't been in the room when we built them. That's not a failure of process — that's what building looks like from the inside.
What I learned to watch for wasn't failure itself but the lag between failing and admitting it. Every team has a version of this: the feature that's clearly not working but has become too embedded in the team's identity to cut. The flow that someone senior championed and so stays through one more iteration and then another. The metric that keeps being interpreted charitably.
The quicker we got at naming inefficiency — saying plainly, this isn't working, and we need to decide what that means for the bigger picture — the more time we had to spend on the things that were. Speed of failure acknowledgment is a skill. It doesn't come from not caring about your work. It comes from caring more about whether it works than about whether you were right.
The big picture has to stay visible for that to happen. If you're too deep in the details, every cut feels like a loss with no context. But when the team is oriented around what we're ultimately trying to be true for our users, the cuts start to look different. They look like focus.
People Don't Want the What. They Want the Why.
UX is not a science. I say that having tried to treat it like one — having watched engagement metrics and run A/B tests and color-coded heatmaps of user attention. Data is useful. Indispensable, actually. But data tells you what people did. It almost never tells you why.
The best thing I ever did for our product was sit next to someone using it and say nothing. Just watch. Watch where they paused. Watch what they tried that didn't work. Watch the moment they understood something, and the moment they didn't. Behavioral data at scale is an average of all of those moments. It's the shadow of the real thing.
What users want is to feel like the product understands them. Not what they're doing — why they're doing it. The reason someone opens an app isn't the same as the action they take inside it. The reason is the thing you have to build toward. The action is just the surface.
When we stopped asking "does the user know how to do this?" and started asking "does the user feel like this was made for them?" — everything changed. Features we were proud of got cut because they were technically impressive and emotionally inert. Features we'd treated as utilities became the things people mentioned first when they described the product to friends.
Delight isn't a flourish you add at the end. It's evidence that you understood someone well enough to anticipate what they needed before they had to ask. You can't fake that with a polished interface. You can only get there by being the user yourself, staying close to the people you're building for, and being honest — faster than feels comfortable — about what the data is actually telling you.