Use the tools you're displacing

This can be seen as an instance of creating features (i.e. in terms of the tool) instead of benefits (i.e. in terms of the user task, their workflow, context, infrastructure, and the user themselves). "Feature vs. benefit" is such a shop-worn cliché that it's easy to overlook the meaning: people don't buy products, they buy solutions to their problems.<p>A different aspect is that if you make a tool that is only useful for 10% (or 1%) of people, if it <i>really</i> helps those people, it is an awesome tool. You don't need to be awesome to everyone - that's for massive mainstream organizations. If you can just help <i>some</i> people <i>a lot</i>, that's enough to get started. In fact, most massive mainstream organizations got their start in exactly that way. Don't feel bad if it's useless for 90% of users; it only matters who it is useful to - if you are loved by just one person, you are loved. (but to reiterate the first point, it's in terms of users, not products).<p>There's also the serendipitous solution: when you make something that is cool in itself, but you can't imagine any use for it. And then some customers come along who do find a use. This path is not recommended by most marketing experts, but it seems suspiciously common in the history of actual entrepreneurs (e.g. one of HP's first sales was oscilloscopes... to Disney... for Fantasia; Honda's creation of the recreational motorbike).

Good advice. However, I noticed that the danger of getting too accustomed to the 'status quo' tools is that you forget what bothered you about them in the first place, and what you wanted to improve. Your first experiences are very important in this, as it will be the same thing that other new people encounter. So write them down...<p>(For example, some tool that initially seems extremely slow, after months of using it you may be used to the delays and take them for granted, even though productivity could be greatly improved if it was faster. Suddenly you're used to all the quirks of the old tool, making it harder to get fresh ideas)

Great advice. I started a nonprofit a six years ago and we had big plans to build a volunteer tracking app and collaborative tool in a hip new framework like Django. Six years later, and we are building a very un-hip tool in Drupal that will ultimately replace three tools we've adopted in the interim (a spreadsheet for tracking hours, a Trac-based wiki, and Google groups). But, this time, after approximately a false start once a year, we finally have traction for the project.<p>To those who are concerned this stifles innovation and "thinking inside the box" -- unless you are lucky, a genius, or probably both, knowing one's problem space intimately is a lot more likely to yield a useful innovation than not.

This is exactly how I'm building my current apps. Before automating anything, I manually help people solve their problem with all the different tools they use, to identify the most annoying gaps in the market.

You should definitely understand how the tools are being used. 1 way is to use them yourself. But that puts a lot of bias on your view of it and you can end up with something that's really useful to you, but nobody else. (Which is only slightly better than not being useful to anybody.)<p>Asking customers how they use it, and really following along, seems to work better for me... At least, when I can get them to answer my questions, instead of the questions they think I'm asking. Still trying to figure that one out.

I wrote syslogit only to find logger about an hour later...<p><a href="https://bitbucket.org/russellballestrini/syslogit/src/tip/syslogit" rel="nofollow">https://bitbucket.org/russellballestrini/syslogit/src/tip/sy...</a>