Lessons learned from a cancelled project(opensoul.org) |
Lessons learned from a cancelled project(opensoul.org) |
1. No constraints. Since it is just me in my free time, no one can tell me what to do, but no one gives me feedback on what not to do. 2. No definition of success or failure. Am I creating a product that I want to exist, trying to polish my skills on the side, learn a new tech stack, or just goof around? Since I can just claim that it's a hobby project when it isn't going well (whatever "going well means"), I don't have anything holding me to a standard, since I haven't established it yet.
Any ideas on how to avoid aimless fiddling around on personal/hobby projects?
Tell yourself you only have a month for the project, and you will release whatever you have in a month. Tell yourself you will never work on new features before fixing all open bugs. Set a goal for a minimal viable product, set it out on paper, and promise yourself you won't do anything else until it is met.
Sometimes, I do extreme constraints. I'll only do the project in straight JavaScript. Or I have to draw 100 pictures, but only with one particular red pen, and none of them can take more than 5 minutes. Or I will shoot only one photo a day, and once I've shot a photo, I'm not allowed to shoot another. I will type for half an hour without ever looking at the screen, no correcting text, no revising thoughts, just half an hour of brain dump.
You learn pretty quickly how to work within your constraints. It's mostly about eliminating distractions, and learning what sort of creative distractions you create for yourself to make yourself feel active without actually facing your fears of finishing.
There is value in learning and trying out things and chances are one of those things will motivate you to do something "real".
To be concrete, two things worked for me: a.) Define deadline, either end of week or end of month. It does not matter much. Your goal is to get the whatever into some finished state - smallest think you can get away with calling done. Done, not perfect.
That will force you to keep scope small and do all that finishing work. Plus, if you pick up something you do not like, it does not matter, end is soon. Next moth up pick up something entirely different. Repeat until you either get bored by that or stumble upon motivating thing.
I found these inspiring: [1] and [2].
b.) Define smallest possible deliverable you can from current project. E.g. proof of concept prototype or tutorial/description blog post. Work on it until you have that smallest possible deliverable. If it was motivating continue, if it was not motivating pick up another type of project next time.
It is similar to a, but it does not have hard deadline. However, point is still to keep it small and try various things before going big.
[1] http://www.gamasutra.com/blogs/RamiIsmail/20140226/211807/Ga...
[2] http://gamasutra.com/blogs/ThomasPalef/20140225/211663/What_...
I know someone who did this and has become disciplined about going back to that list whenever he starts working on the project to make sure the idea he's working on is on that list. If it isn't it's added to the "maybe one day" list on Trello and he switches gears over to some other task. Keeping in mind that tasks could be writing code but they could also be market validation as well. Of course he still has the issue of re-writing half of it every couple of weeks when he thinks the "old" code is now crap and needs to be refactored to perfection. That's a slightly more difficult hurdle to over come in my opinion.
So Github doesn't have managers, it just has Primary Responsible People, who sound an awful like they do the same thing? Just don't call them "managers", because you don't have those. Cute.
Every successful startup eventually discovers that the O(n^2) communication overhead of a perfectly flat org doesn't scale, and needs to adapt to deal with that. The question is whether to develop coordination specialists implicitly or explicitly. Developing doublespeak to protect an idealistic worldview from its incompatibility with reality does seem pathological.
> Everyone on the team suffered from burnout.
> 11 months later, our team decided to cancel the project.
My guess is that the lack of a singular clear vision caused everyone to become disenfranchised / burnt-out in the first six months, and it took another 5 months for people to realize the project wasn't going anywhere.
I think the story underlines the importance of having product leadership - it's all well and good to have a flat organization when the product is already defined and the only thing left is adding features / fixing bugs (as is the case with the github platform), but if you are starting from scratch you can't expect a product grow to grow organically from the combined whims of individual contributors.
> The best software comes from a team where everyone shares a vision, cares deeply about the result, and are motivated to make it happen.
Definitely!
> That level of caring and motivation can only come from people that had a role in crafting the vision and own a piece of it.
Yes, but Design by Committee is a cliché for a reason.
If I was in start-up-central I might have to consider writing that grand 'n' cautionary allegorical tale, entirely fictional yet entirely true, with the plot elements given here and elsewhere. Long term the right book could stand the test of time and be around a long time after the Twitters/AirBnBs/Facebooks have long gone.
- Prospect is a client with 100 employees
- I know the right hand of the CEO (his function is called Special Operations)
- They have an intern that will do data-entry for the next month
- There was a partner meeting on 28 april to discuss the application, but it's been delayed (Busy people over there), but all together + the webapp was deployed 3 days before and the intern didn't had any time to manually input data. So it's for the best
- My expenses could all get payed (currently doing it for free, in my own time), they should be my first big client.
- They will have a deep integration with it (importing newsletters, ...)
- I can sell the application to others.
All in all, what have i learned (and it has been adviced multiple times, just experienced them in real life)
- Get early feedback, when i first discussed the web application, i said that i had an idea that would address his problem, i explained it and i asked him of he could wait another month so, that i would have a early prototype with a minimum of features. I did and he could visuallize the solution and he loved it. 12 people in the company want to contact me (early testers), but i only want to talk through my friend (he is the consultant in this case). He is kinda doing the promotion for me in the company, now i think about it
- Build fast, fail fast. A problem isn't bad, it's how you solve it. I use a github repository to address issues. Get to know the people who have a technical experience employed at your client. Get them to understand that not everything will go smoothly, but you will be on top of it, if there are problems.
- If you're developping a webapp for other people also, you can solve the problems like they want it to. Or you make a general solution and explain them why. You can always find some corner cases where their proposed solution wouldn't work or where there could be dificulties. Explain it to them! Don't be afraid to put something on hold and prioritize your features. You only have x hours a day :)
> Every successful startup eventually discovers that the O(n^2) communication overhead of a perfectly flat org doesn't scale, and needs to adapt to deal with that. The question is whether to develop coordination specialists implicitly or explicitly.
Yep. This is certainly something we feel the pain of and are wrestling with right now.
> Developing doublespeak to protect an idealistic worldview from its incompatibility with reality does seem pathological.
By definition, we don't have anyone that plays the role of "manager" right now (again, for better or worse). I wouldn't call that doublespeak.
The difference being that instead of having someone who is a "project manager", i.e. that's their job title, all they do is manage and set deadlines and such, you have one of your regular people be the responsible person for some project.
Guessing this is what you mean by "implicitly".
It nicely solves a recurrent enterprise problem where PMs have as their primary duty "go to meetings all day every day" and don't have any understanding of what precisely they're managing.