The easiest path is the hardest part

author image Slava Abakumov



Title of the page – the easiest path is the hardest part – may sound controversial for some (or all) of you, but let me explain what I mean.

For the past year and a half, I've been developing a personal project – a plugin for WordPress. It was pretty much a lazy process, with ups and downs in productivity. This plugin became my playground for different new ideas in hierarchy, logic etc. I did a huge plugin rewrite several times already, sometimes partly and sometimes almost completely.

I've invested in that plugin a lot of time – and I still don't have a final result that is ready to be released. Several times I tried to identify its MVP – and it was a pain to list features, cut some of them, prioritize everything and try to stick to it.

So at the very beginning, I was mainly developing for learning and fun, having some not-far in the future deadlines, but not strict. Because of that, I struggled to actually ship something, as I was rewriting and improving all the time.

More than a year gone.

And now I understand, that I'm quite tired of the project, that is not released. The idea still resonates with me though. I need to finish it pretty much quickly to be able to achieve a certain mental milestone of completeness. And after realizing that – I got to a point of the post title.

It's hard to find an easy path to finish the inspiring project with tons of ideas.

To release the project I was working for so long I need to stop pretending that it doesn't have strict deadlines. I need to stop investing heavily in the Research part of the "Research & Development" and more into the Development.

To decrease the development scope I need to come back to a failed (for me) MVP idea, but to streamline it even further. Now I want to create not just a minimum set of features (because it's very subjective), but those that are the easiest one too. And to select the easiest among the minimum viable is very hard. This path requires a lot of planning, prioritizing and Occam's razor to cut into pieces the mature and global idea of a product I wanted to create.

Finding easy features with the highest value, using the codebase and experience of the current state of a product requires dedication, will, and patience.

To achieve that I started to follow the idea I read a week ago (or so) – pay attention to a product each day, no matter how long it takes (minutes or hours). So I've decided to stick with at least 30 minutes daily, which is enough to complete one or two minor things and still stay in the loop.

I hope this problem identification will help me to start "ship fast".


Leave a Reply

Your email address will not be published. Required fields are marked *