The Good Enough Mindset
I'm back. Sorry for the long wait. I've had some cool building to do at Forgd.com, but I want to get back into the habit of writing.
I've learned something over the years that has helped me build stuff quickly. This mainly applies to software, but I'm sure it works in many other areas, too.
I call it the good enough mindset.
It's about finding a functional solution to a problem without chasing perfection.
It's a compromise, of course, as you can't have your cake and eat it too. You won't get a perfect solution (not just yet), but you will get a good working solution much faster and cheaper.
This approach is useful when working on software with budget limitations and time constraints.
Like in any startup, when a feature was needed yesterday.
Perhaps this is just something that only perfectionists need to understand, but it has come in handy for me time and again.
Think of it like this. You identify a problem you want to solve and intuitively aim for the perfect solution.
E.g., the API needs to be fully dynamic.
That is not only overwhelming and likely to deter you from starting but also the most time-consuming and expensive alternative.
A common approach is to break down a problem into smaller, more manageable chunks that can be solved.
I'm thinking of that sort of thing here. Take a step back and consider what a good solution could look like. If a piece of the app can be static, don't go and build the fully dynamic end stage, make it static instead.
When building software for startups, this mindset helps keep the goal in mind: getting a nice feature out to a customer as soon as possible.
I don't disregard the perfect solution; I find a compromise that allows for a much faster delivery. Perfect can come later.
Anyone who works in software has seen this, and at this point, you might be rolling your eyes, saying you've just discovered the known again.
There is a difference, though. The MVP approach is more for validating ideas with functional products that are limited in scope so they can be validated faster.
The good enough mindset is a far more granular tactic that can be applied to every little problem. I don't want to give the wrong impression here, though.
I am not advocating for hacks.
Good enough does not mean you should cut corners; it's about building something that works.
Good enough means you get something to work even though the solution might not be perfect.
Keep perfect in mind and slowly iterate towards it during future builds.
The time it takes to perfect is disproportionate to the actual gain. I'm thinking of the Pareto Principle here, where 20% of the effort gets you to 80% of the solution, but the remaining 20% requires 80% of the effort (i.e., it's often not worth it.)
That's why, most of the time, good enough is just a nice sweet spot. It gets the job done.
This tactic doesn't apply to every situation; some cases will require perfection, but it often helps to keep this in mind.
But tech debt. Yeah, I hear you. If you want to build fast and cheap, you'll have to live with some tech debt. There are ways to mitigate this, but I'll leave that for another time.