I'm working my way through Bob Walsh's book, Micro-ISV.

The first chapter discusses an important topic that I've already blogged about ... how do you come up with an idea in the first place?  This chapter outlines three basic approaches.  First, there's the systematic approach, where you identify industries you're interested in, and keep drilling into it in finer grained research until you have a specific niche idea.  Second, is the "Joel" approach (hey, that's the third blog now that involves Joel Spolsky).  When asked how he got started, Joel said they had three product ideas, and FogBugz was the one closest to being ready to ship, so that's what they focused on.  And third, is the "dammit" approach.

In the "dammit" approach you look for a significant source of frustration in your daily work.  I've been working on my new product, MergeMagician, for a little over a month now.  Of these three approaches, I think the "dammit" approach best describes how I decided on MergeMagician.  I've been developing software configuration management tools for a long time now, first in defect tracking, then build management, so I understand this area well, and there are a lot of opportunities for "dammit" discovery within this domain. 

The MergeMagician "dammit" is that branching and continuous integration don't work well together.  I want to be able to work on features independently of each other, so then when one feature is done, I can ship the product with the new feature.  I never know how long each feature will take, so it would be nice to work on features independently of each other.  To do this, I want to create a branch for each feature under development.  However, I'd also like to do a continuous integration build of *all* features currently under development, so I can work out the kinks of putting them all together.  But there's no automated way of doing that.  With MergeMagician, I can configure the server to automatically merge the separate features into a single integration branch, where I can build and test everything together.  There are lots of use case scenarios other than that one, but this use case is the basis of the MergeMagician concept.

I've gotten quite a bit of interest in MergeMagician so far.  Even though the product is still under development, I want to stay in touch with these early prospects to keep them interested.  To do this, I'm pioneering something I'll call "demo-driven development".  It's very agile-esque, so it's not an entirely new concept.  I'm sure someone else has thought of it and given it a different name.  The idea is to write the minimum amount of code necessary to showcase an idea, feature, or concept of the product.  When it's working, you shoot a narrated screencast of how it works, and then send it to your prospects.  Because you're only sending out a screencast, rather than the real software, the feature doesn't have to be fully implemented.  It just has to be good enough to demo it within a screencast.  When that's done, you go onto the next thing, and repeat the process until the product is shippable.

The advantages of this approach are 1) I get feedback along the way, 2) Keep prospects interested in the product, and 3) Build product mindshare before it's shippable.

We'll see how effective this approach turns out to be.  It seems to be working so far.  The first screencast I did wasn't even the real product, it was just a wireframe mockup of the product.  I sent this to a few people, and they in turn forwarded it on to some people.  Next thing I knew, three people from Microsoft contacted me and wanted to know more about the product!  I'm almost ready to shoot my next screencast, and this time, it will be real, running code.