When building software, there's a mistake called "over-engineering", which consists of building many features that you don't really need because they make sense within the grand design of your code. Most of those features end up not being used, but the complexity that the programmer added to the codebase remains for a long, long time.
The same thing is true for businesses. It's easy to over-engineer your product, to dream up countless features that are obviously necessary for the product to pick up. But, as with software design, most of those features won't be useful, because you don't really know what your users will use.
Here's another great article by Jason Freedman, that makes this point:
(...) if you let those big fictitious plans infect your product development process, you're in a lot of trouble. Product development is about figuring out the single most important problem that exists right now and doing that and only that.
Jason proposes some tips for how to avoid this:
- Read Getting Real.
- Break features into V1, V2, VX - where V1 is only the bare minimum that you need.
- Do things that don't scale (like contacting every new customer personally or signing people up manually).
- Create hypotheses (we've covered this before).
- Use link-testing as trial balloons - i.e. before you build a feature, build a link to it and see how many people click on it.
- Track your speed of experimentation to make sure you're keeping your eyes on the ball.
If you read this far, you should follow me on twitter here.
