I had a related experience with an MVP gone awry. We were building a product that had an entrenched competitor (let’s set aside whether that was a good idea in itself).

We decided to build the core technology and go after some very easy wins first, while laying the foundation for bigger, more complicated wins.

I thought this was a fairly sound plan at the time but we hit three problems that would make me rethink such an approach in the future.

(1) the “easy” use case ended up being significantly harder than expected. I’d guess it took 4x longer to ship than expected, which allowed doubt in the project to run rampant.

(2) the easy wins were smaller than expected (it didn’t help that the system we were augmenting already had some of the features we were building, just implemented in a more ad-hoc fashion).

(3) the more complex and profitable features required significantly new features in the core, the implementation of which had become very complex and the design compromised during the process of shipping the late, underwhelming MVP, and at that point there was no more appetite to continue investing in this technology.