Jose Quesada

In a startup, co-founders pretty much do all type of tasks until they have the initial employees and some organizational structure. Having a sense of who does what, even if the tasks rotate, can be beneficial. It not only helps in having adequate discipline amidst chaos in the initial period, but it also establishes commitment and accountability.

An interesting thing to do is to measure which tasks have the most impact to the bottom line (users? money? some other metric?), then focus on those. Some tasks have a very long arch till they produce results (e.g., most of sales-related tasks), whereas others are easy to measure.

Different times will call for more focus on some roles. That is, roles are in flux. For example, once the product stands for itself, focus on sales may be it. During product building time, CTO role is key, and all hands do some of it. These are the roles we have in our startup:

Product Design & Interface

• Interviews ‘out of the building’, UX
• Hypothesis generation
• Hypothesis testing

Sales

• LinkedIn, Forums
• Cold calls/ relationship building
• Blogging, creating the company image
• Face-to-face client meetings

Support-Tester

• Answer mail
• Close tickets
• Find bugs, open tickets
• Know the product deeply

CEO

• Vision
• Hiring
• Make sure there’s money on the bank

Community manager

• Find ways to make the community grow
• Find where to start a new community next
• Prevents communities from dying (fights, implosion, negative PR)

CTO

• Develops new features
• Fixes bugs
• Sysadmin

Culture ambassador

• Translation
• local knowledge use to detect what works or not

Note that there’s no design role J

Eric Ries, the founder of the lean startup movement, advocates to test heavily before adding a feature. It might be that people will never use it! In fact, if you can mock up the feature, and simply count how many people try to use it, you will get an estimation on whether it’s worth building it or not. However, there are some basic principles that could prevent you from even thinking about poor features.

From Alex Jenter, author of cintanotes we get a rule for when to add a feature:

"features should be organic, effective, discoverable and convenient".

"Organic" means that the feature shouldn’t stick out of the program like an alien body. A non-organic feature IMO is the one that while coming in handy sometimes, still isn’t really connected with the product’s main goal and functionality. (Example of non-organic features: HTML authoring in MS Word, wave editing in Nero Burning ROM)

"Effective" means – should be lightweight and not hurt performance and memory footprint, or be optional to use.

"Discoverable" means – a new user should be able to discover that this feature exists without reading help.

"Convenient" means that a feature is easy to use correctly and hard to misuse, and that a significant number of users will use this feature on a regular basis.

So if the suggested implementation of a third frame will seem to satisfy all these criteria, off we go.

Paul Beckingham, from Task warrior, gives a good rule for when a program feels bloated:

Me: [The features that go unused stay out of the way. We never need to see them. It can seem as simple as we want.]
Paul: That’s been a goal for a long time. Users should not have to "pay" for features they don’t use, in terms of performance or visible complexity.
But this is not an easy balance. For example, let’s say the program has 100 features, but you are aware of only 10. If you want to learn more, but the program doesn’t give you an easy way to find the other 90, then you might consider the software cryptic. Cryptic is a label you might apply if you couldn’t easily figure out some aspect of the software, regardless of how well that may be documented somewhere. If instead the program tries to gently make you aware of more features, then it can become intrusive (remember Clippy?).
At the other end of the scale, if you are aware of the 100 features, but really only need 10, then you might consider the program bloated. Bloated is a label you might apply if you felt there were too many features, and they were getting in your way.

While these two are desktop programs, I think the principles apply for web apps.