Ask HN: How to Finish Projects?
I have always struggled to finish projects, I start out super productive and creative then fissile out when it comes to completing the work.
But I think a lot of the common advice (too simple to work!) is actually helpful:
- Limit scope
As much as you think 'no one will use this without XYZ feature'; no one will definitely use it without it existing at all. Just make the basic functioning product and see below:
- Get real users using it early (release early)
Having real users (perhaps even paying users) using my project, relying on me for fixes/updates, seems to be a nice kick-in-the-pants to fix/work on the project. Even with minimal users or zero-revenue, having that feedback that someone finds what you're doing useful rather than coding into a void is really motivating.
- Build something for yourself
If you need/want to use it, you'll continue to work and improve the project to suit your needs. Theres some additional work likely to make it available for others to use, but if you're using the product yourself often - perhaps thats motivation to see how others could benefit from it as well.
Also realize - it's never 'finished'. If it's a project that you either (a) enjoy working on or (b) actually has users, there will always be more to do. So embrace that and find (a) or (b) early.
It’s true that a product is never finished, there is always something else to add or take away. A project should have a definition of done, there should be a clearly defined point at which the project is finished. Some measurable points that once you reach them, you can say it’s over.
Projects are experiments. Most of the time as you work on it you lose motivation because it become obvious it won’t work or you don’t have something (skills, knowledge, mature enough technology) needed to finish it.
Only finish projects that still valuable for you or for others. Discard the rest ruthlessly, but keep them around. Sometimes parts are useful later.
1. Clear separation between study/preparatory work and deliverable work. There's an inherent tendency to rush and "do it live". And the work done in a workplace setting is often different from a personal project because the preparation is done through countless meetings and reports that gradually uncover specifications by consensus. When it's your project, you have to substitute that with self-feedback and accept that on many days you aren't doing deliverables, you're finding the benchmark you want to set for those deliverables.
2. Your project must be coherent. Any contradiction in its premise will turn into a source of difficulty. At the beginning you can evade this by adding scope: scope lets you ignore contradictions by having more to do, and this is a classic error in many forms of personal project. Then the scope gets out of hand and the project either fails or turns into a monumental struggle. Instead list all assumptions out early on and give them a tournament-style ranking: what's most important, and just as importantly, what contradictions arise by trying to strive for both? Philosophical reasoning can create a ton of leverage for useful progress by clarifying what you really want.
3. Careful attention to workspace. I don't mean just software here, but everything: physically, what does it mean to begin working on this project? Is it easy to resume? Are the materials set up in an ergonomic position or are you always shuffling things around in piles? Do you have some elaborate configuration process? Can you simplify it by reducing the technology? Can you likewise simplify it by redefining your use of technology?
When you ignore the things making it physically easy to reach the end, you create extra work, and eventually it grows into being its own job. Again, there are things people are hired to do that will not see a personal project through. If the project is ultimately "make a business", you may structure it like one, but not every project is or can be that way.
It also helps to have something with real users - it gives you extra motivation to know you're making their experience better each day.
I've written more about the topic here: https://onlineornot.com/unreasonable-effectiveness-shipping-...
Take a project like learning Latin.
There are many steps along the way that get finished, maybe you take a course, maybe you read LLPSI and a bunch of supplementary literature, ... but when have you even learned Latin? When you can read De Bello Gallico, or even Cicero? The vulgate bible?
This is just how projects, in general, tend to be.
That's the theory at least, and it's working better than other things I've tried but it's still tough. Another good feature of this approach is that to an outsider, it doesn't look like I've released one thing, it looks like I've made THREE releases, the free version, the minimal version, and the big multiplayer version. If I had just waited until the "full" version was done and somehow maintained focus, it would look like one release.
Your priority should be to get the core functionality of your project working as soon as possible, even if it's buggy and lacking in features. This proves that you can solve the problem you set out to solve, and allows you to say you've "finished" the project to some degree.
Too often people get caught up in doing things the 'right' way, making sure the code is the cleanest they've ever written, etc. None of this matters if it doesn't result in a working product.
Now I don't mean to say that additional features, bug fixes, and refactoring aren't important. My point is that focus, motivation, and time are limited resources, and these improvements should come after you've established your core functionality and proven that it's viable.
What has changed for me recently is that I now look at these things in terms of "what skill am I training here?", and ofcoirse I have a list of skills I want to master long term.
This has meant that I have given up struggling on some projects that did not reflect on any skills I was interested in, but I am also way more motivated on some other projects.
I recognized myself a lot in this description: https://www.youtube.com/watch?v=A2sS00egAzg
- Maintain a fixed number of max projects in parallel: 3 is my number. When I reach that number, any time I'm tempted to desist on working on any of the projects I have ONLY the possibility of retake any of the group. Of course you still can have unfinished projects but a restricted set of real active projects make you to assume a conscious decisions in contrast with a more involuntary notion that let you think you can retake work on an unlimited number of projects anytime you want (something that almost never happen)
- Less time in perfect: common procrastination is about looking for the perfect design, the perfect stack, the perfect name. Making an effort on identifying and reducing the time you take on this kind of activities helps because you necessarily are going to do real progress in projects. This is particular important later when you realize how working and deliverying your projects make you more confident than just "thinking" on them.
- Involve more people: once the motivation is shared is easier to try to get the projects in a more completed state. Specially when that people is out of your area of expertise. Commonly those first hours of focused and greateful work is spend on things you enjoy doing, once you accumulate a couple of boring tasks, your motivation lose traction. Having people out of your speciality sometimes can unblock/help or directly work on that not interesting activities.
- Close the idea factory: sometimes as serial makers/thinkers the born of a new idea is celebrated and usually that means that a new project is comming. Dont let new ideas to replace the older ones. It doesnt mean that you simply stop thinking in those new ideas that suddenly came to your mind, it means that you need to control the response of those stimules. You can write down on a note book, take a couple of minutes to think in that prospect but you cannot allow that new ideas to replace the more mature and already materialized. It's the most difficult step but is a good training for other useful learnings about let things go.
Done is when those goals are finished, not when the project has all the pieces it could have
If the point is to learn, stop once you've learned. If the point is to play, stop when you get bored of it.
If the goal is to launch something, then, you have to launch it
The silver bullet for me: "only losers do not finish work they started." - Think and grow rich book.
The main key: Persistence. "I will finish it even if I have to fail it thousands times".
A rich guy shared it with me.
Is this really true? In life I noticed that many things are counter intuitive. I have seen people who work hard to finish something don't get good opportunities as they are always busy and the opportunities goes to someone who is free currently.
Projects are not puzzles. They don’t have a generic definition of done.