All great advice, but realize that you cannot just do one or two of them, or incorrectly execute some of them, and expect to be successful.
For example, you cannot take the 'imperfect MVP' and 'iterate quickly' advice as an excuse for poor testing and ignore the part about a narrow focus or listening to customers. I will admit that I have worked on several projects where something like this was the case.
It may just be that some of the projects I have worked on have not been so great (because it is much easier to get those contracts), or maybe this is common -- but what I have seen is startups or dev teams that are iterating quickly on programs that fundamentally do not work or cause their users great frustration. Part of the problem is that people often underestimate the technical difficulty (or perhaps almost infeasibility in some cases) of certain features or impracticality of some UX, etc.
The user frustration one was a government contract so the users couldn't switch to another program. What happened was we built a program for utility workers that required a ton of data entry in the field. Due to slow loading screens or just a ton of extraneous fields or an issue of keeping laptops clean or something else, it was impractical, so they switched to doing data entry in the office on based on paper forms. And then someone decided to give all of those forms to one poor lady in the office. One day I was permitted to visit, and found that due to some bugs we had not been told about and the sheer volume of work, the lady was literally going insane. They were still iterating quickly and adding tons of features on that project when I left.
Here is an example where a project manager may have been using something like the idea of an imperfect MVP as an incorrect rationale for perhaps not evaluating core functionality carefully enough. The product was a home server device. A core feature that was supposedly complete when I came onto the project was a relay/proxy system that would allow multiple connections to come into this device through one port while it was behind NAT. Or something close to that -- it was a few years ago so I don't remember perfectly. But I was initially given the task of working on some lighting animation and only coincidentally discovered that this proxying system and other core networking was not even close to working. I did eventually get a multiplexing thing working for it but they never delivered the system to the initial customer so it was never fully tested.
On another project, it started out as another case of an 'MVP' that actually didn't do the thing it was supposed to do. It mostly did it most of the time, but due to the nature of the project, without an automatic way to detect and correct the 5% of cases where it didn't work, it could not possibly make any significant amount of money. So when I came on, I wasted quite a bit of time trying to make this supposedly already working MVP work, but it had been 'iterated on quickly' and had unmaintainable code and no tests, so I ended up rewriting it.
For example, you cannot take the 'imperfect MVP' and 'iterate quickly' advice as an excuse for poor testing and ignore the part about a narrow focus or listening to customers. I will admit that I have worked on several projects where something like this was the case.
It may just be that some of the projects I have worked on have not been so great (because it is much easier to get those contracts), or maybe this is common -- but what I have seen is startups or dev teams that are iterating quickly on programs that fundamentally do not work or cause their users great frustration. Part of the problem is that people often underestimate the technical difficulty (or perhaps almost infeasibility in some cases) of certain features or impracticality of some UX, etc.
The user frustration one was a government contract so the users couldn't switch to another program. What happened was we built a program for utility workers that required a ton of data entry in the field. Due to slow loading screens or just a ton of extraneous fields or an issue of keeping laptops clean or something else, it was impractical, so they switched to doing data entry in the office on based on paper forms. And then someone decided to give all of those forms to one poor lady in the office. One day I was permitted to visit, and found that due to some bugs we had not been told about and the sheer volume of work, the lady was literally going insane. They were still iterating quickly and adding tons of features on that project when I left.
Here is an example where a project manager may have been using something like the idea of an imperfect MVP as an incorrect rationale for perhaps not evaluating core functionality carefully enough. The product was a home server device. A core feature that was supposedly complete when I came onto the project was a relay/proxy system that would allow multiple connections to come into this device through one port while it was behind NAT. Or something close to that -- it was a few years ago so I don't remember perfectly. But I was initially given the task of working on some lighting animation and only coincidentally discovered that this proxying system and other core networking was not even close to working. I did eventually get a multiplexing thing working for it but they never delivered the system to the initial customer so it was never fully tested.
On another project, it started out as another case of an 'MVP' that actually didn't do the thing it was supposed to do. It mostly did it most of the time, but due to the nature of the project, without an automatic way to detect and correct the 5% of cases where it didn't work, it could not possibly make any significant amount of money. So when I came on, I wasted quite a bit of time trying to make this supposedly already working MVP work, but it had been 'iterated on quickly' and had unmaintainable code and no tests, so I ended up rewriting it.