[PragmaticPulp]

Mockups are part of the iterative process. Building a mockup to test is part of what I was describing.

The point is that you can't simply make a mockup, assume it proves your hypothesis, and then go heads-down building the exact product shown in the mockups for 6-24 months and expect great results. Instead, you need to iterate both the mockups and the product in parallel, engaging with the market along the way.

As in the example I provided, sometimes customers will claim to love your mockups but then decline to pay for the product when it arrives. It's one of the first things every product manager learns in the real world.

> It's a good way to separate the technology decisions from the business decisions.

Trying to separate technology from the business decisions is a mistake. At the start of the process, you need technology, product, sales, and business to be tightly intertwined.

Dividing the labor and sending different roles in different directions is a mistake at an early stage company. You need to get everyone working together to iterate over and over again.

[mushbino]

I don't mean a hard separation in terms of roles, but I agree with your general sentiment. The reality, in my experience with startups, is that an MVP is built by an engineer or a couple of engineers and it's launched as quickly as possible to get market validation. The thought is usually along the lines of "we'll launch it, get feedback from customers, and then quickly iterate." The reality is usually that the MVP is launched and the company is stuck supporting that MVP and the company is afraid to make changes because they got a customer to give them money (enough perceived validation) and they're stuck supporting the MVP they've just launched instead of iterating. I've seen it so many times that I refer to it as "the MVP trap".

Also, User research can be done in a way to account for the fact that users will say they love something, but actually never use it. I've done it many times.

All of these things that you've mentioned should be done in tandem, but in practice, that's pretty rare. The good thing is that it creates market opportunities for other companies. Amazon is a more extreme example, but it's basically the business model of AWS. Another example is Terraform. HashiCorp has done a poor job of keeping up with user needs so there are add-ons or straight up replacements coming out of the woodwork to fill the feature and experience gaps that have been around in TF for years and years. You will see more competitors to TF and other HC products coming up for exactly this reason. They aren't even the close to the most glaring example, but just the first thing that came to mind.