The Anthropology of Software
|
The Anthropology of Software |
|
|
|
February 27, 2006 Where is the Pain? In the software industry, real pain is what makes you want to strangle someone at the company that made the software you are using; real pain is when you are losing money because you can't get your systems to integrate knowledge and manpower; real pain is when software breaks down or is unnecessarily susceptible to human error; real pain is when all of the available solutions have one significant shortcoming for your needs like not supporting your platform or too large a footprint. All these real pains create tremendous opportunities for startups. The pain that my current product CMarkup solves is the complexity and overhead of XML solutions for simple XML purposes. Experienced and practical C++ programmers take one look at those big things out there and say "Yuck! There's got to be something small and easy for such a trivial problem" and then they go online and find my product. But CMarkup was just a nice accident as I explained in I See Markup, Part 3 - Transition To Commercial Product. The idea I introduced in my last post "Here Is My Idea" is the peer to peer spreadsheet idea that was in my mind when I started my company in 1999, though I have never brought it to market. I made the mistake in "Here Is My Idea" of not powerfully invoking any real pain. Instead of describing pain I listed a few annoyances. Real pain is the number one means of communicating a good idea because everyone can understand real pain. As Joel Spolsky wrote: Don't start a business if you can't explain what pain it solves, for whom, and why your product will eliminate this pain, and how the customer will pay to solve this pain. The other day I went to a presentation of six high tech startups and not one of them had a clear idea for what pain they were proposing to solve. I saw a startup that was building a way to set a time to meet your friends for coffee... On one hand, my peer to peer spreadsheet idea is still somewhat of a solution in search of a problem. The are a number of ways to specialize and I plan to do that. On the other hand, my idea did come out of specific problem area for which I believe there is still no powerfully appropriate technology, the U.S. government budget coordination process. And that remains the area I would love to pursue again someday. In The Right Idea?, Gavin Bowman lists a whole bunch of great points on selecting and proofing your idea. At the end he really nails what it all boils down to: If that sounds like a lot of steps and a lot of work, it is, but it's a lot easier and less painful than building a product that nobody wants. Or, than building something and then trying to figure out who wants it and how you're going to get it in front of them. My peer to peer spreadsheets idea is meant to address many of the pains in current distributed work-flow, approval, and publishing solutions. These are not new ideas, I just plan on executing a solution very specific to the needs of the domain. The challenges faced by systems that need to bring information managed by many people into one place often fail to get a good balance between management and data flow. There is the centralization bottleneck that works against the productive autonomy of a dispersed group of information managers. Peer to peer functionality supports managers in the field to control their own processes before dialing in to the central office. Centralized solutions have a bad dependency in times of movement and or turmoil when Internet access is unreliable, and being dependent on a server they make it difficult to move the center of operations. I believe the pain amongst many existing customers of budget coordination systems is very real and that they, or the contractors providing their systems will benefit from a core product to address these pains. There are still a lot of questions to answer about this idea though, so stay tuned.
|
|
