Someone this week asked me about how to execute quickly. In bigger companies, it’s typical for things to bog down - there are lots of stakeholders, lots of requirements, products are older and larger and mature, all of that. In those contexts, it’s understandable that the overhead slows the teams down. The problem is that folks often get used to that pace and don’t really know what to do when they are working on something that’s new and unburdened.
Another challenge is that folks often confuse activity with progress. “I’m so tired, I sat in meetings all day, look at this deck I made!”. It’s not to say that no meetings or documentation is useful on the way to defining and building a product, but they’re not the same thing as making concrete progress towards user value or product vision. This is something I see a lot - teams working very hard, on tangible output like meetings and documents and research, that doesn’t actually do much to build a product.
Moving fast can be uncomfortable. It often means doing things before the whole picture is clear, learning as you go, and being nimble about fixing mistakes. It’s a different skill set than elaborating large designs in a legacy system. But the best way to learn, and the best way to convince someone that your approach is right, is usually code. Most of the products I’ve built have felt different live than I anticipated and evolved accordingly (I’m working on a product right now that’s doing the same thing).
Speed is as much of a choice as anything else - it has costs, tradeoffs, and cultural demands. It’s not something that just happens, it’s a different way of arranging and prioritizing (and rewarding) activity on a team. Everyone wants to be faster - the question is whether you also want to give up some of the things that are incompatible with that and do the things that it demands.