Usually I go to sleep not knowing what feature or bug I'm going to work on the next day. I have a huge list of major and minor projects all vying for attention.
So how do I decide what do work on? I agree that a startup should focus on working smarter (as opposed to just harder). I'm the first to admit though that I don't have a particularly scientific or even spelled out process on how to do so, but the following are the principles I generally try to apply.
- First, I like to tie everything back to distribution, i.e. people using your product. You should be tracking quantifiable long-term metrics, e.g. number of signups, uploads, shares, whatever. For my search engine startup, my main metric is number of direct searches/time.
I believe tying back to distribution entails rephrasing the question what feature or bug should I work on next to if I work on X, will it result in significantly greater distribution, and if so, how much? Note that greater distribution can come from either existing users using the product more or new product use from new users.
Once answered, you can then roughly focus on areas you think will have the highest marginal benefit with regards to distribution. For example, something directly related to distribution, e.g. a marketing effort or social/sharing feature, probably has a high marginal benefit.
You can't forget word of mouth distribution though. Most of my distribution to date has been via word of mouth, and I believe that is due to product. It is a great place to be for a product-oriented person like myself when you can work on product and it also helps distribution. But you still can't get sucked into the false belief that product features trump direct distribution features all the time, because they don't.
Similarly, how many of your users (including potential users) will the feature effect? Something that appears on a site all the time generally should take precedence over something that only occurs in a small corner of it. Of course that is mitigated by severity and impact, but you get the idea.
- After distribution, the second principle I apply is using real feedback to substantiate my decisions. Such feedback could be actual data, or, more often in my case, user interaction. Using these data sources you can really get more of a sense about the marginal benefit beyond your initial guessing positions.
You usually do need some kind of user base to get these kind of signals, but often not as big as you might think. I've tested various feedback button sizes, shapes and positions and found that moving them around has a dramatic effect on the amount of feedback received. Same goes to links to forums, chat rooms, etc.
I encourage all startups to essentially maximize these input streams since the data is so valuable. Using feedback appropriately greatly improves the chances you are actually working smarter (as opposed to just thinking you are working smarter).
- Third, I like to put a lot of minimum viable products (MVPs) out there. MVPs are not just for the initial version of your product. Maybe they should be call minimum viable features (MVFs).
In other words, I like to ship code. It's not always the prettiest code, but it allows me to move on to another feature/bug and let the first one simmer.
By letting it simmer you allow yourself and your users to experience it in some form, and suggest incremental improvements that you often didn't think of at design time. I absolutely love this aspect of shipping code. Again, the bigger the user base, the bigger the effect.
The other, perhaps bigger reason, to do a lot of MVFs is it isn't readily apparent a priori what is going to work and not work with regards to distribution. It's sort of like A/B testing in that it can be non-intuitive. By planting a lot of different seeds, you are spreading your risk a bit hoping that some of them will blossom, or more often than not, prompt you to think of new related or combined efforts that eventually turn into something meaningful.
- Fourth, I batch things. There are so many silos of code and each takes some time to really get into and be effective. So I try to wait until there is a decent amount of stuff to do in that area before jumping in, which maintains efficiency.
- Fifth, I inject randomness or happiness or whatever you want to call it. Since none of this is an exact science, I generally work on things that strike me in the moment as interesting, given the above constraints. That's not always possible but it contributes to my not getting burnt out.
Despite the above, my process breaks down from time to time around the edges. For example, I like to be as open and responsive as possible. That means though that I'm often engaging in twitter/email/forum/etc. conversations about minute aspects of my startup. Is that working smarter? Probably not, but it feels right.