The problem of too general tools

There was a nugget of a comment today on the Lean Startup Circle from William Pietri:

However, having made the mistake of building too-general tools before, let me offer a bit of advice. Tools may be general, but people only have specific problems. So if you want an individual to choose to use your software, you have to solve their specific problem well. Generality is a consequence of extracting the similar bits of specific problems, not a goal on its own (however much that appeals to gadget nerds and toolbuilders like us). Real users mainly appreciate that generality later, if they ever do, when they have a second specific problem that is now easier to solve because they’re familiar with your tool.

It struck me because I’m slowly starting to see this is part of the problem I’m facing with my educational tool, Eduglu. Right now I pitch Eduglu as a “social learning platform” that includes a number of learning tools out of the box and can easily be extended to meet specific needs of the learning organization that adopts it. But when I pitch, I don’t seem to be moving anyone. It seems my pitch is falling into the too-general tool trap that William warned against. Yes, an adopting organization can use it for all sorts of things, eventually, but people don’t buy things to solve “all sorts of things”. They buy things to meet very specific needs.

Or as Sean Murphy put it in another thread, narrower focus & deeper pain is better.

The hardest part of starting a company I think is learning to understand how others think and feel about something. As a toolbuilder, I’m very used to evaluating generic tools and understanding how to apply them to solve my specific problems. But most people aren’t as adept at that art. I need to understand how to get inside people’s heads and intimately understand what they need and the learn to present what I’m building in a way that it will be obvious to them how my tool will solve their problems.

Subscribe to get updated on new posts!