Designing in a Startup

My job at an AI startup was to make things better. A year in, I could not tell you whether anything had gotten better.

I joined in my last year of college, when I was 21, right after I suspended an internship at a big tech company. I am not going to write about what that company did wrong. I want to write about how long it took me to notice anything at all, and the order I noticed it in.

This is one startup and one designer, and I do not know how much of it generalizes. But if you are weighing your first job at an early company, these are the things I did not know how to look for.

I did not walk in and see how the company made decisions. I saw the surface. Then I spent a year digging.

A strong designer in the wrong environment can still produce decent work. But the environment sets the ceiling, and at 21 I could not have told you where mine was.

Where I started

My work was on the surface, and on the surface it went well.

I built marketing pages. I gave feedback on product design and polished details. I designed the social content, the posts, the videos. This is real work, and I was decent at it.

Surface polish is fast and legible. A refined website and a packaged launch read as taste, and for a while that is enough, because the artifacts keep getting better. It is also why a product can look beautiful from the outside and still feel wrong from the inside.

The first thing I noticed

The polish stopped changing anything.

I did a lot of interface redesign. I still think they are good case studies. But they landed exactly the way the team had predicted before I started: these are nice to have, people don't pay after seeing details, people pay for the features they need.

No metric moved. So the work went to the bottom of the priority list, which was also taken as proof that the prediction had been right. It is a closed loop. Detail work does not get the room to prove anything, and not proving anything is the reason it does not get the room.

So I started giving feedback further upstream, which is what you are supposed to do. Vercel asks design engineers to do exactly this:

Push back when clarity, craft, performance, or trust is at risk

Scope small enough to do it well

I agree. "Push back when <your scope> is at risk" works for almost any role.

But pushing back is only the input. What happens next is not up to you, and that half is usually missing from advice written for designers.

The feedback was heard. It was rarely argued with, which I first read as a good sign. Then I noticed the shape of the answers. A proposal would come back with what a large company in our space does, rather than anything about the proposal. Or it would come back as two options that were never mine: I suggested we turn cameras on once a week to build some cohesion, and the answer was that this is a foreign habit and we don't work that way. The idea was not rejected. It was routed around.

External precedent, personal characteristics, national habit. Any of them will do. Each one ends the conversation without the conversation happening.

The listening was real. It just had no consequences, and listening without consequences is decoration.

The clearest evidence is not any single rejected idea. It is that the problems in how we organized and worked together were identified early, by more than one person, and were still exactly the same a year later.

Asking for more scope

At that point I thought the problem was authority. I was in my early 20s and I was often told to have an ownership mindset.

That advice is not wrong. But ownership is not only a mindset. It is also a permission structure.

You cannot ask someone to act like an owner while denying them the ability to own meaningful parts of the work. If every important decision is already decided elsewhere, ownership becomes theater.

My colleagues saw me as the guy who makes the interface better after the feature is implemented. That sounds like a compliment, and for a while I took it as one.

Here is what it actually meant. Say the feature is forwarding several messages to another agent. I would not design a new dialog for that. I would make the existing branch chat robust enough to do the same job, and then there is no dialog left to design. What came back was: I asked you to make the dialog better, why are you asking me to remove it?

The dialog was my scope. Whether there should be a dialog was not.

It took me much longer to ask why the dialog was so obviously right to everyone except me. There were reasons, and they were not stupid ones.

More features felt like a moat. For a small company being copied quickly, a longer list is something you can point at, in a deck, on a pricing page, in a comparison table. That instinct is a real answer to a real fear.

There was also a reference. Everyone on the team had forwarded a handful of messages to a contact in WeChat, so forwarding a handful of messages to an agent looked like a problem someone else had already solved. Copying a shape that already works is fast and usually safe. What it skips is whether an agent on the receiving end is the same problem as a person on the receiving end, and that question costs a week nobody wanted to spend.

And there was the clock. When the metric is flat, shipping is the only thing that reliably feels like motion. Thinking does not look like progress, and deciding not to build something looks even less like it.

I should be fair here, because I was not carrying any of that. I had no runway to answer for, no investors, no flat month to explain to anyone. "Slow down and find the real problem" is easy to say when the bad quarter is not yours.

But the pressure explains the decision. It does not change what the decision leaves behind.

The version of this I felt every week was that the product could only grow. Every problem was answered by adding: another feature, another button, another link, another doc. In over a year I cannot remember a single thing being removed. Even after the product repositioned, the parts that no longer fit the new position stayed exactly where they were.

I could arrange a surface like that. I could not decide what belonged on it.

Following it upstream

A company's first product is not the app, the website, the brand, or the roadmap. It is the team.

The team is the machine that makes everything else, which means the team's confusion becomes the product's confusion.

And at an early startup, the founder is the bone of that machine. What counts as good enough, and what must never be touched, are downstream of one person.

Once I started reading the company this way, the product stopped being confusing.

A product that cannot subtract comes from a strategy that refuses to choose. We wanted individual users and enterprises, the domestic market and the overseas one, low intent and high intent users, all at the same time. The roadmap was not a set of bets. It was a set of everything.

The same gap showed up between what was said and what was optimized. We raised in dollars and talked about going global, then spent the actual weeks adapting to the domestic market, under a story about serving both. You could read the result directly off the interface: all in one, promotions everywhere.

It showed up in what money was for. There was budget every month for verification badges on the team's social accounts, and no budget for the tool we worked inside all day.

And it showed up in the team, which is to say in the first product. A year in, we had never had an offsite. Several colleagues had no idea what the others looked like. When someone left, they left quietly, and the rest of us found out later, in a meeting, when their name happened to come up. We were remote across two countries, and one side's time was treated as more expensive than the other's, including whether attending was optional.

None of these are craft problems. All of them are decisions. The question was never whether the team had taste. It was whether taste reached the place where decisions get made.

The bone

Here is the trap I could not see from any of the layers above.

My boss would find a problem he believed needed solving. He believed X would solve it. He asked me to execute X.

I was not being asked to solve a problem. I was being asked to implement a conclusion. The problem had been closed before it reached me, and everything I was good at was pointed at the part that was never in question.

I do not think anyone around me had stopped caring about the problem. It is that nothing in how we worked made caring about it pay. A solution can be shipped, demoed, and counted. A problem can only be argued about, and the arguing costs the week nobody felt they had.

When I proposed a different direction, the answer was not about the direction. It was about me: make more design first, then we can really talk. I was 22, and that was treated as a fact about my thinking.

A job I disliked would have been survivable. Losing my own read on things was not. It is the gaslight effectIf you're repeatedly told X is wrong, you are gonna start believe it even you are not at the beginning., and it was slow enough that I did not feel it as damage. I felt it as becoming more reasonable.

When the core product thinking is unclear, design becomes rescue work. I kept improving the surface, and the product did not become more true. I adjusted the words and refined the flows, and something was still off.

Eventually I stopped believing the problem was the button, the layout, or the copy.

The problem was that craft never reached the bone.

What I would ask now

None of this was visible from outside, and I do not think a smarter version of me at 22 would have spotted it in an interview. These are things you can only ask about, and then watch.

Does the team share something underneath the professional layer, or only the professional layer?

When feedback is heard, does anything change afterward? Not whether people listen. Whether priorities move.

Is the ownership real, or is it scope with the decisions already taken out of it?

When the pressure is on, does understanding the problem still count as progress here, or does only shipping count?

I am genuinely grateful for what that company gave me, including this.