Minimal Effort | Daily #256

From an entrepreneur's perspective, I understand the minimal effort strategy. What’s the biggest impact we can achieve, with minimal effort.

Similar to selling copied paper notes in a high school, rather than creating a whole web app to download some notes. Sometimes you don’t want to over-engineer a solution where the impact decreases over time.

But I think this strategy has crept up in all of engineering. Apps that randomly have a new feature that is too random. Or worse, doesn’t work. They tell you that they are experimenting and want feedback.

How can I give feedback when the feature is complete shit.

Let’s say this new feature can actually solve your problem.

An example could be removing the need to use a spreadsheet. But every time you open this feature, it crashes, it is too hidden, the experience is dog shit, it’s not readable and more negatives.

But it does solve the problem of not needing the spreadsheet anymore.

Yes, I will give the feedback I don’t need the spreadsheet anymore. But because of all the other negative aspects, I would rather go back to the spreadsheet, cause at least it works.

I see this so often and hate it as an engineer. Why not create something amazing and then ship it instead of a dogshit MVP version. MVP doesn’t mean that the experience needs to be shit just cause it can solve the problem.

Also, when you adopt this strategy, you will eventually have too big of tech debt. If your MVP is too unstable and usable, eventually, you have to rewrite it anyway. When you want to move fast, rewriting something is the last thing you want to do in my experience.

This minimal effort MVP mindset needs to be re-evaluated case by case. Yes, sometimes you don’t need to over-engineer and a simple solution solves the problem.

But when the simple solution is below average quality, cause of many reasons and you ship it, then you are shipping dogshit.