I think this is a very classic "waterfall" world view.
In many cases, the problem can only be understood through many failed solution attempts. It could be because the actual problem is novel. It could be because there is a different way of thinking about the problem that is not apparent studying only what a customer does today with the limitations of the software that they have right now.
The point of "move fast, break things" is to address this fallacy that anyone can fully understand a problem before attempting the solution; it is often the case that in attempting a solution, one comes to understand the actual, valuable problem.
Waterfall means designing and building everything before rolling it out to users. Researching a problem before you start tackling it is just general good advice. You can be more effective while moving fast and breaking things while still taking some time to know where to move and what is ok vs not ok to break.
I think this is a very classic "waterfall" world view.
In many cases, the problem can only be understood through many failed solution attempts. It could be because the actual problem is novel. It could be because there is a different way of thinking about the problem that is not apparent studying only what a customer does today with the limitations of the software that they have right now.
The point of "move fast, break things" is to address this fallacy that anyone can fully understand a problem before attempting the solution; it is often the case that in attempting a solution, one comes to understand the actual, valuable problem.
Waterfall means designing and building everything before rolling it out to users. Researching a problem before you start tackling it is just general good advice. You can be more effective while moving fast and breaking things while still taking some time to know where to move and what is ok vs not ok to break.