Three things big tech does that startups should copy, and three they shouldn't

In short: copy the demo culture, the habit of measuring what users actually feel, and the discipline of writing ideas down properly. Don't copy the approval layers, the urge to build for every device at once, or the long distance between the people who build and the people who use.

For about a year, from 2023 into 2024, I was a research engineer in human-computer interaction at a large hardware company. The work was applied AI on consumer hardware. I prototyped new features, demoed them, and helped judge which ones were worth putting into a product.

On the side, I build and run a small AI platform of my own. There I'm the engineer, the designer, the support desk and the person who reads the billing emails. Doing both at once makes the differences very clear. Some habits of a very large company are worth stealing. Others would sink a company of one.

Copy these

1. Demo, don't describe

In my team, an idea wasn't really an idea until there was something to try. A rough prototype on a real device, in front of the people who would decide. A working demo answers questions that a document only raises. Does it feel fast? Does it make sense the first time? Does anyone reach for it?

A demo ends arguments that a document starts.

Startups say they do this and often don't. They write a spec, debate it, then build. Build the ugly version first and let people touch it.

2. Measure what the user feels

On devices, the number that matters is often latency: the gap between what you do and what the device does back. On one project, the change I made that people noticed most was cutting latency by about a fifth. Nobody would have noticed a model score that much better. Everybody notices when a device answers faster.

Small teams tend to measure what's easy to log, like model accuracy or server uptime. Pick the one number a user would feel and put it on the wall.

3. Write ideas down properly

A large company makes you write an idea up properly before it gets people and time. That forces a particular kind of writing. What exactly is the problem? What already exists? What, precisely, is new here? It's uncomfortable and it's useful. Often, writing that page shows the idea is weaker than it felt, or that it's really two ideas.

You don't need a formal review board to get the benefit. A one-page note with those three questions, written before you build, saves weeks.

Don't copy these

1. Process sized for thousands of people

A big company needs reviews, sign-offs and gates, because a mistake ships to millions of devices. That process is correct for its size. At a startup it just means nothing ships. If the person who decides and the person who builds are the same person, a review meeting is a meeting with yourself.

2. Building for every surface at once

A large company thinks across many product lines, and it should. It has teams for each. A small company that tries to support every device or every customer type before one of them works ends up with several half products. Pick one surface and make it good.

3. Distance from the user

In a research role inside a large company, your audience is mostly internal. You demo to product teams, who talk to other teams, who eventually talk to users. That chain is long.

Running my own product, the first person to tell me something is broken is a user, and they tell me fast. That feedback is the only real advantage a tiny company has. Don't add layers between you and it because a big company has them.

Side by side

The short version

None of this is a criticism of how big companies work. Most of their process exists for good reasons, at their size. The mistake is borrowing the process without the size.

Try one this week

If you're building something small, pick the copy column item you skip most often. For most people it's the demo. Take the feature you've been describing in documents, build the roughest version that runs, and put it in front of one person who would use it. Watch where they hesitate. That's your spec.