Lessons learned from a cancelled project
opensoul.org
Lessons learned from a cancelled project
1–10 of 17 posts
Re: Lessons learned from a cancelled project
#2I'm working on a personal project, and I find myself struggling with some of the same problems.
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?
Re: Lessons learned from a cancelled project
#3I'm working on a personal project, and I find myself struggling with some of the same problems. 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 c…
Just my 2¢, but find a mentor or adviser of sorts, who can keep you honest and accountable to a plan, and give you good feedback on product features or direction that you may not be able to fully appreciate from the inside. This might look like someone you know or are connected to through your community (whatever you consider that to be), or it might look more like an entrepreneur's group of people trying similar things.
Re: Lessons learned from a cancelled project
#4I'm working on a personal project, and I find myself struggling with some of the same problems. 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 c…
I think you've answered your own question. Create constraints and goals.
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.
Re: Lessons learned from a cancelled project
#5I'm working on a personal project, and I find myself struggling with some of the same problems. 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 c…
I had the same exact problem with a side project that spiraled out of control and was eventually cancelled in favor of a new job. What I had just started at the end, and what friends have done, that seems to work really well is to use something like Trello or Asana (which is a semi-ironic recommendation since my project would've been a competitor to these two) and lay out your immediate goal right now. Don't write any more code until you have that figured out. Then start entering tasks/ideas/features/bugs/etc that get you from wherever you currently are to that point.
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.
Re: Lessons learned from a cancelled project
#6I'm working on a personal project, and I find myself struggling with some of the same problems. 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 c…
What about this: fiddle around and just learn/goof until you stumble upon something that you will want to finish. There is not that much value in finishing something no one needs and there is no point in turning hobby pet time into work unless there is some gain (money, inherent motivation, proud feeling) from it.
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_...
Re: Lessons learned from a cancelled project
#7I'm simplifying it (probably too much), but those lessons seem to be some of the things our PM brings to the team. Was this team all engineers/QA?
Re: Lessons learned from a cancelled project
#8I'm simplifying it (probably too much), but those lessons seem to be some of the things our PM brings to the team. Was this team all engineers/QA?
You are right. For better or worse, we have not had traditional PMs at GitHub. Often that is a role played by what we call a PRP (primarily responsible person). That person is often an engineer or designer.
Re: Lessons learned from a cancelled project
#9I'm simplifying it (probably too much), but those lessons seem to be some of the things our PM brings to the team. Was this team all engineers/QA?
You are right. For better or worse, we have not had traditional PMs at GitHub. Often that is a role played by what we call a PRP (primarily responsible person). That person is often an engineer or designer.
> Often that is a role played by what we call a PRP (primarily responsible person).
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.
Re: Lessons learned from a cancelled project
#10Earlier quoted context omitted.
You are right. For better or worse, we have not had traditional PMs at GitHub. Often that is a role played by what we call a PRP (primarily responsible person). That person is often an engineer or designer.
> Often that is a role played by what we call a PRP (primarily responsible person). 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…
Is the barely-masked disdain really necessary?
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.