This post is about one common mistake startups often do. We did it when we built the PiX’n’PaLs photosharing website and later kind of repeated it in our e-commerce solution (read the story here). The mistake I am talking about is implementing more features without fully understanding what all the implications are. There are always a lot of great ideas popping up, but you can probably only pursue 1% of them. Trying to do to much is a common cause of failure; thus, the saying “Startups don’t starve, they drown“ has become so popular. In order to help others avoid drowning, I decided to list 10 things for startups to think about before implementing another feature. These are based on my own experiences, others’ stories I have heard or read about and a lot of common sense.
Experienced product managers use the word NO often. When I was younger I didn’t get them. Now, having been an entrepreneur myself, I understand them perfectly. I have really started to like Steve Job’s famous quote “Innovation is saying no to 1000 things”. Focus is essential and when you have one good idea you always find thousands of other ideas that would be cool. It is so easy to fall into the trap of implementing ideas here and there.
It is vital to understand that there are huge hidden costs in implementing a new feature. A feature may be really cool and seem to take only a few days to implement. An inexperienced product manager may happily keep pushing this kind of features into production even before product-market fit is found. The feeling is good when progress is being made and there is a lot of positive feedback from others. If the product gets poisoned with various different features that don’t fit well together before product-market fit is found, the company will be in a “feature hell”. At this stage it will be hard to find product-market fit, since all changes are slow and require a lot of work.
Let’s look a the different reasons why features can be poison:
1. Every new feature implemented requires more effort (the obvious one)
Every new feature obviously needs implementation effort. Additionally, a lot of documentation, manuals, FAQs, legal documents, etc. need to be updated. Some of these documents can be seen as features as well. Do you really need an FAQ or a manual? Will they become liabilities and slow you down? Furthermore, startups often put a lot of effort into analytics, which is used to learn about customers. This means that usage of the new feature need to be tracked. Finally, there may be a need to monitor the health of the feature in some cases, which will also result in more implementation work. What the developers initially thought would be a one day task suddenly became a huge operation that requires several people to get involved.
2. Every new feature may need maintenance and support
Having a new feature requires more maintenance work; someone needs to analyze all measurements collected, monitor the health of the system, etc. The new feature may also require more sales- and customer support.
3. Every new feature uses resources
New features may use more memory, hard disk or some other resources. All these have a cost.
4. Every new feature increases complexity
New features will increase the complexity of the system. This is dangerous for a startup still in search for product-market fit. Very often the complexity grows exponentially, because features have dependencies. This means that when you specify (or implement) feature X, you need to take into account that features A, B, C, etc. may or may not be used together with feature X. Sometimes it is possible to design everything in such a way that they are independent. But often when we solve real world problems that real customers have, we may not have that luxury. A well thought through spec and good software design will help deal with the complexity, but only to some degree.
5. Every new feature will cause some loss of flexibility
When there are more features and more complexity (indirectly), it will obviously be harder to do changes. Both technical- and business/logical complexity will require that a lot of time is spent on analyzing the impact of a change or new feature. All combinations must be thought through. This is very bad for a startup that has not yet found product-market fit and may still have to pivot.
6. Every new feature increases risk of bugs
Complexity will make it harder for developers to understand what the impact of a change is going to be. Also, high logical complexity will often also result in underspecification of new features and everybody will not share the same understanding of how the new feature should work together with everything old. Misunderstandings will lead to bugs.
7. Every new feature may introduce security holes
As complexity can lead to bugs and low quality of code, these can in their turn lead to security holes. Like with bugs, if the complexity is high and it is unclear how something is supposed to work, you will easily end up with some security holes in both code and application logic.
8. Every new feature must scale
The more features you have, the more potential bottlenecks you have. Complexity and dependencies between features are going to make it even harder to scale. Consider a consumer web application, which hits product/market fit and starts to grow rapidly. You have to cache content shown to end users. You have a requirement that the data must be fresh (changes visible immediately). The more different features there are that can indirectly have an impact on the data that is going to be shown to end users, the harder it is going to be.
9. Every new feature results in a longer learning curve
The more features and complexity there are, the longer it will take for new team members to be able to work independently and become productive. This applies to both developers and other employees.
10. Every new feature which is not used by the user will decrease usability and value
Every feature that is not used by the user, will distract the user from achieving his/her goal. Many studies show that a lot of options may result in the customer not choosing any because making the decision becomes so hard.
Additionally, when new features are added that do not perfectly fit into the software or are not fully thought through, the overall experienced completeness of the product will decrease. This happened to us in PiX’n’PaLs. If you thought our first version felt 50% complete, after we had added some more features that were not really core, you probably felt it was 40% complete.
At the time we realized that we should have been spending 80% of our time fixing old and 20% developing new, we had already implemented so many features that raising the degree of completeness required a lot more effort.
What happened in PiX’n’PaLs was actually that new features introduced new requirements. First our puzzle was missing a few pieces. Instead of looking for these pieces, we started building new puzzles next to the core puzzle, so the result was that we were missing even more pieces to the puzzle than when we started.
A startup should build a Minimum Viable Product (MVP). The product is either viable (can be used to validate a hypothesis) or it is not viable. The product cannot become any more viable by adding more features.
What to do then?
A startup needs to try out things and they may be complex, since customers need real world problems to be solved and the real world is complex.
Here’s some advice:
- Seriously try to keep things simple before product-market fit is found. Look for different trade-offs to reduce dependencies between features if possible.
- Narrow down the target customer segment.
- Focus on only one revenue stream, one Growth Engine, one X, one Y, etc. at a time. And do it well. Fail fast and move to next one.
- Avoid automating everything. Experiment by doing manual work.
- Really force yourself to think 80/20.
- Remove features and old stuff that do not add enough value.
- Focus on the goal and how to get there. Is this new feature really the way to get to the goal? There is most likely one biggest problem at the moment that you must solve in order to succeed. That problem is so hard and frustrating that it feels good to concentrate on some other tasks instead, like implementing some other new cool features. Don’t fall into this trap!
- If possible, keep things modular and reduce dependencies between features
- If you can identify key components that are unlikely to change during pivots, go for a Service Oriented Architecture (SOA). This is easier said than done ;)
- If you find yourself in the “Feature Hell”, try a Zoom in pivot, which means detecting one feature that is used, and making that the product and hiding everything else. If that is too hard to do, due to complexity, take the knife, be really aggressive and cut off all dead meat (features) from the product. This is what I would do if I would continue PiX’n’PaLs or any of my other old projects.
