Enterprise vs. Startup: Two Different Ways of Working

Why it's hard to do 0-1 in a big company

As we head towards a wide launch of our product in Adobe, I am increasingly getting pulled into many conversations, and I have been trying to think about how this experience differs from a startup experience.

I believe the main difference in working style comes down to this:

• In a big company, there is a checklist for most things, and the focus of the entire team is to complete the checklist. Almost everything needs to be done. If something is not done, you need to justify why and get an exec bypass.

• In a startup or 0-1 journey, the only goal is: what is the bare minimum we need to do to test the hypothesis? You have a hypothesis, you test it, you learn from it, and then you solve only the bottleneck for the next experiment.

These are fundamentally different ways of working

The big company method relies on the assumption that immediately after launch, people need the product. That has somehow already been validated. And if we build it right, market it right, get the right legal approvals, and so on, we will have served the company and our customers. Also, the cost of getting something wrong is extremely high: brand reputation, customer trust, and so on.

The startup approach assumes mostly the opposite. The assumption is that the product you have in mind is probably something no one wants. Almost every idea will fail. And if you know that, why spend a lot of time making sure your backend can serve a million users, or that every single thing on the screen is pixel perfect?

Also, remember that the bar for switching users from their current workflows to something new is that the new product has to be 10x better. So if you assume that your product truly has to be 10x better to succeed, start thinking about what actually matters and how we should prioritize.

What is good enough for the next experiment?

For example, if your app has 99% uptime instead of 99.99% uptime, which might be the gold standard for scaled products, is that good enough for the next experiment? If the curves in your app designs are 20% off from the recommended guidelines, is that a big enough problem that users will stop using your app? If your app does not exactly match the design patterns of other apps, will users stop using it because of that?

That is not to say there is no minimum bar. There absolutely is. In fact, the only thing you should focus on is the thing that has gotten bad enough that, without solving it, you cannot run the next experiment.

For example, in our case, our UX had become so bad in the last few weeks that I was convinced no one would even get to the final page and realize the value of the product. Before that, I felt the positioning of our product required major changes because what we were actually delivering and what we told people the app would do were very different.

Why can’t you parallelize all of this?

Interactive model: Play with the coordination drag model to see how alignment half-life collapses as the rate of change increases.

In a big company, you have amazing people with expertise in every function: marketing, design, research, engineering, legal, privacy, security, GTM, and more. So why not have everyone work in parallel?

• Because each thread is moving so quickly that keeping all the threads in sync slows everyone down to a halt.

• This is why generalists are so helpful in the early stages. You need people who can move across product, research, design, engineering, positioning, and customer conversations as the bottleneck changes.

• This is also why, whenever startups go through a major pivot, they often become leaner and then run experiments again. It is nearly impossible to quickly turn a huge loaded ship.

The bottleneck keeps moving

For two weeks, the bottleneck could be design because the UX is so bad that people will not even get to the value of the app. For the next two weeks, it could be research. For the next two, it could be infra scaling. Whatever the bottleneck is, that becomes the main thing most of the team is solving.

Hence, the following are important:

1. Early team members being generalists is important because as the needs of the project evolve, people wear different hats.

2. It is important that the function that is not currently a blocker does not interpret low attention as low importance. That function gets the least attention for a while, but that is the best possible state if it is not blocking the next experiment.

3. The problem gets harder when some of these functions are external to the core team. They may feel ignored or offended because they do not see the bottleneck shifting day to day.

4. The team has to communicate the current bottleneck clearly, so people understand why something is being handled now, later, or async.

Low attention is not the same as low importance. It often just means: this is not the bottleneck for the next experiment.

Some other learnings

• Customer is king. A customer meeting overrules a meeting with your manager, an interview, or a regular standup you might have scheduled. If we are pre-PMF, time with customers is the highest-leverage use of time.

• Track the percentage of time spent with customers v/s internally. If internal alignment starts taking more time than customer learning, something is wrong.

Some more guiding principles

• If you want to make a project go faster, remove people from the active decision loop; do not add more people to it. That does not mean their work is not valuable. It means every additional person adds coordination cost when the direction is still changing.

• You can delete the work required instead of working harder and burning yourself out. Say no to meetings. Move things async. Reduce scope. Decide what does not need to be solved yet.

• Do not optimize for scaled-product quality before validating product value. There is a minimum bar, but not every enterprise standard is the bottleneck for the next experiment.

What should be the focus?

I truly believe the most important thing people do at work is make a small number of exceptionally important decisions. Those 5% of decisions change almost everything. We should focus on improving the quality of those decisions instead of trying to complete checklists that may not matter for the next experiment.