Ask HN: How do you determine which project you should work on?
I normally do the classic pro/con list (sometimes only to ignore the result and do whatever pleases me the most) but i would like to know the approach(es) other people take.
12 comments
When I'm presented with a project (by myself or someone else), my thought flow is usually like this:
1, Is this project interesting to me? I usually trust my gut on this one and what I'm interested on is temporally-variant. I can only apply my self 100% to things I find an interest in.
2, What is the market viability of this project? I do a bit googling around to see if there are any existing implementations of this product. I try to think of usage scenarios and I will google for communities who might need this product, read about what they have to say and find out more about their needs so that the implementation of the product can be geared towards them.
Even if a product has 0 market-demand, I might still work on it because of step (1) and I simply treat it as a learning experience ( such is the case of kpicturebooth.com ).
3, I work out the logistics - can I work on this on my own ? - if the project was presented to me by someone else, what is the team like? - how long will it take, can I fit it into my school schedule?
If I deem the project infeasible, I might try to work on one part at a time or get people to help me.
1, Is this project interesting to me? I usually trust my gut on this one and what I'm interested on is temporally-variant. I can only apply my self 100% to things I find an interest in.
2, What is the market viability of this project? I do a bit googling around to see if there are any existing implementations of this product. I try to think of usage scenarios and I will google for communities who might need this product, read about what they have to say and find out more about their needs so that the implementation of the product can be geared towards them.
Even if a product has 0 market-demand, I might still work on it because of step (1) and I simply treat it as a learning experience ( such is the case of kpicturebooth.com ).
3, I work out the logistics - can I work on this on my own ? - if the project was presented to me by someone else, what is the team like? - how long will it take, can I fit it into my school schedule?
If I deem the project infeasible, I might try to work on one part at a time or get people to help me.
On your point 2, the one thing that I would add is to:
1. Try out the existing implementation (a little gap analysis with your idea)
2. Even though analysis from (1) above does not come out with much pros, the project might still be a viable one, depending on the effort needed
1. Try out the existing implementation (a little gap analysis with your idea)
2. Even though analysis from (1) above does not come out with much pros, the project might still be a viable one, depending on the effort needed
I've been thinking about starting a side project as a learning experience. So what are the ideas and knowledge that you have found most helpful in your current projects? I think having goals about what I wanted to learn would be more beneficial than just doing something, so I'm wondering what all of you want to learn in your businesses/startups.
>>> what are the ideas and knowledge that you have found most helpful in your current projects <<<
This is kind of a broad question.
For ideas, I usually look at the usual sources for inspiration such as my favorite applications. One of my favorite things to do is to read academic journals and try to implement some of the algorithms in a way that can be used by consumers.
>>> what I wanted to learn would be more beneficial than just doing something <<<
Well, to me this is a trade off.
If I just want to "learn things", I'd probably spend all my time in MATLAB experimenting with interesting code snippets that no one else in the world will see or use. ( I would also apply to grad school... something which I'm trying to avoid at this point ).
On the other end of the spectrum, I don't want to be one of those "web developers" who spends all their time writing the same "to-do-list" or "my own blog system" in some cool new language.
In the end, I think there needs to be a balance of challenge and practicality of the projects which I work on. It has to be technically challenging enough to keep me interested and yet it has to have some practical value so that at the end of the day, I have something to show for it. =)
This is kind of a broad question.
For ideas, I usually look at the usual sources for inspiration such as my favorite applications. One of my favorite things to do is to read academic journals and try to implement some of the algorithms in a way that can be used by consumers.
>>> what I wanted to learn would be more beneficial than just doing something <<<
Well, to me this is a trade off.
If I just want to "learn things", I'd probably spend all my time in MATLAB experimenting with interesting code snippets that no one else in the world will see or use. ( I would also apply to grad school... something which I'm trying to avoid at this point ).
On the other end of the spectrum, I don't want to be one of those "web developers" who spends all their time writing the same "to-do-list" or "my own blog system" in some cool new language.
In the end, I think there needs to be a balance of challenge and practicality of the projects which I work on. It has to be technically challenging enough to keep me interested and yet it has to have some practical value so that at the end of the day, I have something to show for it. =)
I have a really tough time with this, and often bounce back and forth between side projects.
Erdos was supposedly really good at helping people pick research problems to work on which would have just the right difficulty given their capabilities. I can't find the exact quote, but it was in the book "The Man Who Loved Only Numbers"
pg had some advice in an essay on high school: http://paulgraham.com/hs.html
Excerpt:
"Put in time how and on what? Just pick a project that seems interesting: to master some chunk of material, or to make something, or to answer some question. Choose a project that will take less than a month, and make it something you have the means to finish. Do something hard enough to stretch you, but only just, especially at first. If you're deciding between two projects, choose whichever seems most fun. If one blows up in your face, start another. Repeat till, like an internal combustion engine, the process becomes self-sustaining, and each project generates the next one. (This could take years.)"
Erdos was supposedly really good at helping people pick research problems to work on which would have just the right difficulty given their capabilities. I can't find the exact quote, but it was in the book "The Man Who Loved Only Numbers"
pg had some advice in an essay on high school: http://paulgraham.com/hs.html
Excerpt:
"Put in time how and on what? Just pick a project that seems interesting: to master some chunk of material, or to make something, or to answer some question. Choose a project that will take less than a month, and make it something you have the means to finish. Do something hard enough to stretch you, but only just, especially at first. If you're deciding between two projects, choose whichever seems most fun. If one blows up in your face, start another. Repeat till, like an internal combustion engine, the process becomes self-sustaining, and each project generates the next one. (This could take years.)"
Here at SmartFlix we're pretty analytical about it.
When we're batting the idea around, we create a page in the wiki, and the first section is "rationale / analysis". In there we put the number of customers it will attract, or the plausible increase in revenue per customer (with some error bars), then calculate a value for this (a 5% chance of an extra $1 from each of X thousand customers = $Y). We also calculate the cost (we have a nominal price of $75 per engineering hour, and half of that for a design or marketing hour). If a project doesn't pay back its investment in a year, we don't do it. If a project does look to pay back its investment, we then rank order it against other projects to figure out which to do first.
When we're batting the idea around, we create a page in the wiki, and the first section is "rationale / analysis". In there we put the number of customers it will attract, or the plausible increase in revenue per customer (with some error bars), then calculate a value for this (a 5% chance of an extra $1 from each of X thousand customers = $Y). We also calculate the cost (we have a nominal price of $75 per engineering hour, and half of that for a design or marketing hour). If a project doesn't pay back its investment in a year, we don't do it. If a project does look to pay back its investment, we then rank order it against other projects to figure out which to do first.
I try to start by capturing all my good thoughts into a notebook. The second part is I try to review all the things I have captured on a daily, and weekly basis. If I am not currently working on a project, then I try to be open to inspiration, total cheese I know, but I find that if I "force" it, like for the next hour I am going to work on having a good idea, I fail. My best idea/projects have all come in a bit and pieces and then they all of a sudden form into a solid idea. When I have an idea, I then try and build a prototype as fast as possible. At that point I am usually in a position to decided if I should continue, shelve, or give up. In the end whatever you decided to do, make sure you try and work with the intention of getting better at something. If you do that, in the long run it doesn't matter if you fail at a project because you still learned something along the way.
I don't know how many of you will read this, but i thought of posting this new finding that has helped me.
I read Joel's functional spec article some time ago and decided to give it a go. I started writing functional specs for three ideas i was thinking of working on (but obviously i don't have the time to work on all three).
I had a terrible time writing the spec for one idea,one idea was right in the middle between and there was the one i was truly passionate about(not obvious at first sight though).Writing these functional specs helped me find which of these possible projects was the most interesting and promising.
Hope one of you finds this useful.
Here's the link to Joel's article: http://www.joelonsoftware.com/articles/fog0000000036.html
I read Joel's functional spec article some time ago and decided to give it a go. I started writing functional specs for three ideas i was thinking of working on (but obviously i don't have the time to work on all three).
I had a terrible time writing the spec for one idea,one idea was right in the middle between and there was the one i was truly passionate about(not obvious at first sight though).Writing these functional specs helped me find which of these possible projects was the most interesting and promising.
Hope one of you finds this useful.
Here's the link to Joel's article: http://www.joelonsoftware.com/articles/fog0000000036.html
First make sure your enthusiasm for an idea is not resulting from hidden assumptions you have made and not realized. Examine all your assumptions.
Also try to avoid falling prey to any cognitive biases. There is a list of them at wikipedia that is probably worth acquainting yourself with. Perhaps you might favor one idea over an other just because you have been thinking about it more recently. This would be related to the Recency Effect - increased saliance and recall of recent stimuli. Thus you will weight the benefits (and drawbacks) of recent ideas more than the benefits (or drawbacks) of past ideas.
One way around this might be to rate your ideas at multiple times after rethinking various past ideas fully.
http://en.wikipedia.org/wiki/Recency_effect
Also try to avoid falling prey to any cognitive biases. There is a list of them at wikipedia that is probably worth acquainting yourself with. Perhaps you might favor one idea over an other just because you have been thinking about it more recently. This would be related to the Recency Effect - increased saliance and recall of recent stimuli. Thus you will weight the benefits (and drawbacks) of recent ideas more than the benefits (or drawbacks) of past ideas.
One way around this might be to rate your ideas at multiple times after rethinking various past ideas fully.
http://en.wikipedia.org/wiki/Recency_effect
1. Do I find it interesting? If it woke me up from my sleep or prevents me from sleeping, because I am so interested in working on it - it's time to work on that idea.
2. If not that extreme - is it worth losing X months of work on my current project. When I set code aside, I can rarely every just jump back into it. I tend to rm -r and start all over. So, is this new idea worth those 6 months I spent on my current project?
3. If not - it goes into Backpack in order of "excitability" and I'll get to it eventually.
2. If not that extreme - is it worth losing X months of work on my current project. When I set code aside, I can rarely every just jump back into it. I tend to rm -r and start all over. So, is this new idea worth those 6 months I spent on my current project?
3. If not - it goes into Backpack in order of "excitability" and I'll get to it eventually.
Instead of a backpack, I use a "uservoice" page for projects that are interesting but I'm not going to do them. Then others can add comments, add ideas, implement the ideas, ...
Similar to Tantek's reasoning for wikis, I like sharing the ideas that I'm not going to implement any time soon
Similar to Tantek's reasoning for wikis, I like sharing the ideas that I'm not going to implement any time soon
That's a really good idea - I may have to look into doing that.
I don't place ideas in Backpack to keep them in the "walled garden" - it's just the most web-accessible, easy to use area I have for information of that nature (I keep losing sticky notes).
I don't place ideas in Backpack to keep them in the "walled garden" - it's just the most web-accessible, easy to use area I have for information of that nature (I keep losing sticky notes).
I start it, and then see how it's going a few days in. If it's a struggle then it either probably isn't something I want to be working on, or there's something wrong with my premise that's keeping me from really "feeling it." So back to the drawing board -- or I put it aside for something else. Sometimes, I'll revisit something I've previously set aside because I'll have thought of a new way to do it or new spin on it that makes more sense and makes me more excited to work on it.
I came up with this, but I never use it:
Through the day, I have a fluctuating "importance threshold". During free time the threshold is very low; during work time it's high. At any given time I do the most fun thing that's above the threshold.
Through the day, I have a fluctuating "importance threshold". During free time the threshold is very low; during work time it's high. At any given time I do the most fun thing that's above the threshold.
Consider your passions and your skills and try to focus on projects at the intersection of the two.
I look at every project that is a candidate. The I ask: why would I want to do it? Concrete things, not generals like "I am passionate about it" (that's a prerequesite). I make this list for every candidate. Than I cross-check each reason with each candidate. The same for contra. The project with the most votes wins.