The more projects that I've shipped from conception to completion, the more I'm believing that there are two fundamental phases for each project, and you need radically different management philosophies for each.
Phase 1 is "will it work?" You get a vaguely-specified business requirement, maybe some intuition that a market could be better served by software. And your job is to build that software, and figure out exactly what's required for it.
In phase 1, you need the creative-genius programmers, and they need to work in small teams with large amounts of autonomy. Because most of what goes on in phase 1 is failure: you are learning about the problem space and all of its corner-cases, you're trying out different approaches, and you're hoping to make that one creative leap that brings everything together. Prototyping is invaluable, refactoring is important, and deadlines and estimates might as well be plucked out of thin air. To successfully run a phase 1 project, you often need to be able to redefine success. When I read the article, my first impulse was to say "Well, the biggest fuckup management made was to not cancel the feature, because they had ample evidence that this feature was not worth the cost." A startup's entire life is spent in phase 1, because once it's exited phase 1 it's called a "high-growth company", and their version of redefining success is the pivot.
Phase 2 is "make it work". You start phase 2 with a working prototype that demonstrates the feasibility of what you're hoping to do, but still has a lot of rough edges. And your job is to polish it down to something that the customer wants to use daily. That means fixing bugs, improving usability, adding admin tools & logging, improving performance and reliability, ensuring security, etc.
In phase 2, you need a much larger team of disciplined, detail-oriented engineers. Because debugging can be parallelized. You need unit tests, you need formal processes, you need issue trackers, you usually need PMs or management. It helps to break things into user stories so that you know you're always making progress.
I see a fair amount of hate for Agile and Scrum on HN, but these are tools, and specifically tools for Phase 2 work. I use them myself, for my own projects, because I find that they help me manage all the little tasks involved in bringing a product to market. The hate comes from people who misapply them: startups who have big-company management who blindly apply what worked at their last employer, or established companies that are trying to do new green-field projects and believe it works the same way improving your 10-year-old product works. But similarly, there are a large number of abandoned startups and open-source projects that never bothered to cross the Ts and dot the Is, and so are largely useless to people.