The single toughest thing I battle with in building any product is fighting feature creep. Especially when I’m doing my own thing.
As I dig into coding my latest and greatest thing, I notice all sorts of spots where I could throw in something extra and interesting. But if I give in to every one of these impulses the product will become bloated and confusing (especially to new users; which is *all* users since this is a new project).
To stay on track, for this specific project, I have to force myself to continuously ask “how does this help the coach?” or “How does this help the athlete?” (depending on which user the feature is geared towards of course).
And then, even if there is a good answer to that question, I have to ask “Is this needed from the start?” and “Would this specific feature cause someone to subscribe? Would not having it stop them?”.
Still - it’s easier said than done. Having a strong and simple story helps. Understanding the core ‘why’ I’m trying to get at helps more…but probably the single biggest trick I’m using to staying on track with the product is to simply “build then delete”.
When I just can’t prevent myself from taking a tangent in the code, I just give in and build. Then, once it’s done and my 'must build’ gene has been satisfied, I can go back and re-ask the above questions.
At this point, if I can cut the new thing I just spent time building, I do (well actually, I archive it rather than completely cut it – because 9 times out of 10, it is something I expect to release down the road as the service and user base grows).
Giving into this approach can blow up the schedule (though I don’t actually have one at the moment), and it’s probably not a great thing to do if you’ve got a team of developers trying to work together…but for me, at the current stage of my new thing, it’s a great and freeing way to 'keep building’.
This post has received 40 loves.
Kevin has a day job as CTO of Veritonic and is spending nights & weekends hacking on Share Game Tape. You can also check out some of his open source code on GitHub or connect with him on Twitter @falicon or via email at kevin at falicon.com.
If you have comments, thoughts, or want to respond to something you see here I would encourage you to respond via a post on your own blog (and then let me know about the link via one of the routes mentioned above).