Adding new features before the bugs of an old feature is somewhat fixed is basically regarded as bad practice in software development. Every bug you leave unfixed will cause problems in new features, will take longer to solve later cause you forgot what it was, put you in a lot of technical debt.
On the other side startups should focus on learning what features the customers need and ship as fast as possible, iterating as much as possible.
The key here would be saving time, learning early what the feature should be will save time but fixing bugs early before introducing new layers of programming will also save time.
So how should we prioritize between bugs and features in software startups and find a balance that works?
Who is leading your development and what project management approach are you using? If you are using scrum that answer is defined for you. If you are using waterfall, or RUP the answer is defined for you. If you are just winging it, then this is one of those things you need to answer for yourself.
Ah, the old "feature creep" question... I struggle with it too. I have about 50 new features in the pipeline for EQUINOX-3D, 20 usable, 10-15 polished-enough for release...
Very true about technical debt.
It's a very important balance to maintain.
1) Show-stopper bugs (crash, data loss, unusable UI etc.) always before any new feature
2) Severe workflow slowdown issues always before new features
3) Memory leaks before new features, unless the customer is still trying to figure what he/she wants and only doing short test runs
Letting the customer know the limitations is critical. In the early phase, some bugs might not be show-stoppers, and it may turn out that the feature was not wanted anyway, so there's no value in fixing the bug (other than educational).
Before I address this question, it's important to note that bugs fall into several categories, which determine their severity:
Bugs in category 1 should almost always take precedence over other work, since the last thing you want to do is create dissatisfaction. Bugs in categories 2 and 3 can be considered to be Technical Debt, which is analogous to financial debt.
Choosing to take on technical debt in the short term often leads to greater rewards in the long term if you can use it to gain more opportunity by delivering sooner. However, it's important to manage technical debt in the same manner as managing financial debt. Over time, the "interest" charged mounts up. I've witnessed first hand many organizations that accumulated so much technical debt that they eventually became paralyzed due to fighting production fires, and were unable to deliver any new features to market entirely.
Successful software organizations often, as a strategy, choose to take on some technical debt in order to deliver on time to meet an opportunity, and then devote a cycle to "pay off" this debt by focusing on bug fixing and refactoring instead of developing new features. It's also important to apply best practices in developing software (such as TDD) to avoid the unintentional accumulation of technical debt from bugs.
You definitely want to do a mix of bugs and features. Try to think in milestones/sprints (which can be a week or two long), and figure out what can be done during that time. A developer can work on a portion of a feature, plus X amount of bugs within a milestone. You want to make sure you include a mix of high and low priority bugs, because you don't want the low priority bugs stuck in limbo. It's up to you to decide what constitutes a "low" or "high" priority bug, but that setup seems to work best in my experience.
My first thought is, according to Lean, that ne features are too important for the MVP that I'm building, but often simple bugs can have bad impact for the early adopters. So, I think that the right balance is to solve the bug that can improve the user experience and continue to focus on the features we need for the MVP
It's like managing cash flow versus accrued value. You have to manage both. Accrued value is how much the company is worth and is the long term goal, but if you spend too much cash on things for the long term, your company will be unable to pay its employees and will die.
So, fix bugs like crazy because you will lose customers with buggy software. But do the new features, too, or you won't get new customers. It's all about balance. Kind of zen-like.
Oh, and get your developers to do things like code reviews to stop bugs from getting into the product in the first place. Code reviews offer so many benefits that it's hard to believe they aren't universal. There are nice open source tools for this, as well.