Speed matters, but only when you know what to build

We can ship trash faster every single day. We need strategy and really smart decisions to know what to ship.

I've repeatedly learned that when you're doing something new, zero-to-one, the temptation is to kind of think about... rush and say to go to scale before solve. So I've always said to my teams solve before scale.

Startups is a game of trying to get distribution before the incumbent can copy. It's this kind of concept of escape philosophy.

Most teams can move faster. But faster for what? We can ship trash faster every single day. We need strategy and really smart decisions to know what to ship.

Don't assume it's going to solve all your problems. Don't assume it's going to do autonomously be able to give high quality results of every case. But what can you now build now that you have magical duct tape?

One phenomenon we've seen when teams are building things really quickly with AI is that the more AI-generated or assisted they are, the more generic they tend to turn out. Going fast can actually slow you down in the long run.

All you're going to do is really annoy the users. Because, say, in the future they are, 'Hey, I'm still interested, but I don't want to use that product because I already tried.' It's like, 'No, no, you can totally use it now.' 'I already tried. I had a bad experience with them.'