2023-06-18
Most technology or product oriented blog will usually follow the formula of “how to draw an owl”.
Sadly that’s not really helping. Sure you probably learnt something along the way and that’s important; but you’re leaving a trail of projects ever started, never finished.
Ok so, how do we finish things? Well, first, you have to start the right way.
The key to finishing projects is two folds.
Dream up something achievable.
First, you have to dream up of something achievable. For this, the 80/20 rules works well. You should be comfortable with understanding 80% of what lays ahead and roughly have 20% of unknown.
The reality is that most often it lands in the 50-50 range, because you can’t know what you don’t know. But that’s ok. Sometimes, knowing less about what lays ahead is actually helpful. If you knew the pit of hell in front of you, you’d probably never step a foot in it!
The key though is that you should be comfortable with the learning phase of what you don’t know. That is, if it’s a technology or product, you should know where to look for answers or who to ask to.
Second, you should need what you build.
Build what you use and use what you build.
If you design and build something, build what you use and use what you build.
From this base, I’d call this a good start. Because you’re building something you have a rough idea where you’re going with it, and you’re building something you’re going to use. As you use it every day, or stare at it because you need it: you’ll fix “the next thing”, and chip at it every day.
This is key… If you’re building a replacement for something, then that thing is dead to you. Remove it from your life and rely on your own device. For example, I was unhappy with the offering of IRC clients on macOS. They’re old, crufty, have terrible UX, are missing modern features, or are unmaintained. So I’m writing my own. I use it already. For example, at the moment, it can read most content but can’t write easily. So I’m fixing that because all the other irc clients are “dead to me” and I’ll use my own sauce.
The same has occurred with music players, I wrote 2 for macOS (different intents) and 1 for watchOS.
I wanted rain radars on my watch, so I built it. I wanted music in the car without pulling out my phone, so I built it. I wanted a site generator to work the way that I wanted to work, so I built it. I wanted an app to keep track of my TV shows, so I built it. The list goes on.
Because I’m writing what I need, it allows me to cut a whole lot of features. So one might say “but hang on, this isn’t a full featured X” - sure, I agree, but that is the true MVP that works because it scratches that itch. It’s a working, living product. When I have some free time, I add all the things I don’t need you’d expect to have. Also, I share my work early on and gather feedback from friends, which helps knowing with what to tackle next. It might be something that doesn’t annoy me, but annoys someone else. It keeps me honest about what I can call finished.
By using what you build every day, the work will call you out. Things will be nagging at you. You’ll want to fix them, and that, is how to finish.
This leaves us with two open ended questions
One could argue that finishing something means everything from a shiny website, to a built in payment system, and to be available on the app stores. Personally I don’t see it that way, because I see everything a breathing living thing from its creator(s). As things constantly evolve, nothing is ever trully finished. My measure of finishing is something being used in production. It becomes the main driver, it’s used, there are no alternative. So it may change and morph on a weekly basis and resides a lot in the good enough range, but it is finished as it is in use. Commercial success is such a vast pitfall that I don’t consider it being part of being finished.
Having high standards for yourself pays off. This guarantees that you’re not putting stuff out there half broken. You have to be able to identify crusty corners and fix them. They should nag at you. Half broken features is not finished. Being bug free is a requirement and bad UX is a bug.
What I find in the projects I have never finished are things that weren’t to be used. The “what ifs” projects. Or “This ought to be better” without tangible, measurable metrics.
For example, “let’s fix Twitter” is such a vast topic without measurable metrics or tangibles, based on a popularity contest with open standards no one would agree on, or that “already exists”; it’s a can of worm you’re not going to tackle. The grassroots approach is the only way to solve these type of projects, where you build something for your school, your work, your friends - and it works for them. Building something for swaths of humans in a vacuum would rarely work without intimate knowledge in the field.
That is the dark side of pitfalls projects. For example, where you dreamed up something unachievable. Note that this may be temporary, as you gain further skills, the impossible becomes possible. But sometimes, at the time of engaging in a project, you just walk off a cliff.
Finally there are things built for other people. Those are hard to maintain because you’re not the use case, so you need to understand how it’s lacking for them to keep it working for them. Many companies even fall through with this. For example a company acquired a small company and took over their product. They don’t have intimate knowledge of the said products and eventually end up ruining them, alienating their users in the process.
Note that this does not apply in the context of paid work.
Working on a paid product is building what you use because you use the derivative of that product - money. However, these are hard projects to start by yourself. It’s easier to work on a product that is already producing revenues or for someone paying you for your work, rather than dreaming up a product that you don’t need, that someone else “may need” and “may pay you” for it. In fact, I feel this is practically a very hard thing to finish.
It’s far easier to sell something you need yourself with the chance that someone else might find it useful, than dream up something someone might need.
It’s also far easier to finish something you yourself need, for the simple fact that you cannot define what the MVP is.
But I never had any issues finishing products I was paid to write, because the derivative of the said product was already coming to my account. So you might be afraid of contracting if you have a long trail of unfinished projects, but the simple fact that you’re paid to finish something is really a major motivator to finish something. So I wouldn’t worry too much about finishing paid work.
If you’re having trouble finishing things you start, question whether it is because you walked off a cliff and this thing was beyond your reach, or whether you lost interest in it because you didn’t really need it. I really feel that if you’re replacing something, start using it as soon as possible, and remove the lacking option off the table. The work will be nagging at you to be finished.
Finishing things and putting them out there in a form or another is thoroughly enjoyable and addictive. It’s an incredible driver at widening your field of knowledge. And before you know it, you’ll be dogfooding most of your productive day using your own products. Anything that bothers you becomes fixable. I hope this short essay helps you in that direction.