At Mercor I’ve learned two things: the quality of people and your speed of execution are the most important things.

Sure there have been a few other lessons - about leadership, communication and alignment, and solving problems at the for the business and not just technically. But those are the two biggest.

A few weeks ago we had Incident X in class Y of incidents. We proposed solution S which would solve the entire class of incidents and work was begun on a spec for this. This week, we had a low-severity incident in class Y. Since we didn’t ship solution S in time, it was scarier than it needed to be.

If you don’t ship your thing quickly:

• your managers/leadership will ask you for updates about it frequently
• other teams will ship it for you
• users will get annoyed (why hasn’t X thing been shipped)
• your energy, excitement, and reputation may decrease if you are thinking/talking/building a thing and the thing hasn’t been shipped

Especially for bugs, where there is a positive feedback loop between reporting a bug and hearing back that it has been fixed. These should be fixed ASAP because it incentivizes reporting small things. Extremely small bugs/slight UI misbehaviors can cause serious incidents if the user relies on the wrong expectations. When bugs go unfixed, the feedback channel goes silent — people stop reporting because they don’t see results. But when you close the loop quickly, others notice and start reporting too.

There are a few things that determine when something gets shipped:

• Quality — you need to be OK with shipping something with bugs. These will get reported. Best case scenario is your app/feature is full of bugs but people use it anyway because it is so useful. Worst case is they use it once and never use it again because of the bad experience — which is why you should calibrate your quality level to the types of users/level of retention/virality you need for the product. If you’re shipping an internal tool like we are at Mercor you can plead, persuade, and hope with the passage of time that good feedback will overcome any initial issues.
• Alignment — with external teams and your managers. Your managers/PMs will be most likely to not want to ship quickly, because their name is on the line and they might be worried about ability to fix bugs that come with more usage. External teams can almost always block or delay things if there are data, security, or correctness issues, so engage with them ASAP.
• Bandwidth — any feature involves mini features/improvements and bug fixes. Balancing this is critical and you should make sure you are fully able to make high priority improvements immediately, so you retain users and create a great viral experience that brings in new users.

Quality

It is fundamentally impossible to assess the quality of your app/feature unless you are the target audience. There are many reasons for this:

• any large production app will have too much surface area for a dev to test manually
• when you test with dummy data (small amounts of data) it may change the performance or rendering of a given page
• you know how to use a new feature, users won’t. It may be unintuitive/hard to figure out and require docs, inline instructions, or a redesign

The next thing

Users spend hours in your app — take advantage of that. Figure out what they care about, and build that next. Chop the rest. For many features, especially w/ LLMs, you will never really know what users really want until you launch.