First time founders confuse getting feedback with convincing people.

They do mental incest by bouncing ideas off the same people every time.

They are too proud to simplify their startup because “then it would just be [insert their real problem here]”

Interesting format for startup meetings, we could adopt this at demodinner:

I strongly advocate speaking openly about things I did wrong – and I advise you to do the same. Maybe it’s because I am better in seeing my mistakes than the things I did right. And maybe it’s therefore easier for me to share at least the things you shouldn’t do instead of things you should do. But learning from failure is imho always worth sharing.

If you want to share you own failures or want to learn how to avoid those, join the upcoming meetup of London’s new event format Failboat. It’s no VC, no Press, no bullshit. Just founders talking straight honest.

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

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.