[cstejerean]

Not start coding before you fleshed out the design? Not design until you've identified a market? Sounds like a recipe for never getting anything done. That might be the proper way to tackle things when you have a big upfront costs, but generally for software you can just start coding on things you find useful and interesting. If others are interested, great, you've got a company. If not you just have a useful product and then you can move onto something else.

[tom_rath]

How can you create a useful product if you haven't identified the use?

[chaostheory]

luck in combination with the Max Strategy (continually trying different things all the time):

a lot of products did not identify their use before hand, or their real use was discovered accidentally after they were made.

post it notes - started as a failed adhesive. a coworker found that it worked well using it with paper and a gospel hymn book

snood - (a very popular puzzle bobble variant) the programmer made it because he was bored in grad school

linux - started as a hobby by a bored phd candidate

silly putty - a failed rubber substitute designed for WWII use

the list goes on...

[demallien]

I'd agree with that. The one piece of software that I have written that people choose to use (as opposed to being forced to because the code is embedded in the widget they just bought)has got to be the most trivial thing I have ever done - a multicast bridge that I hacked together one afternoon. It has some trace that is very useful for the proprietary multicast protocol that we use.

That stupid bridge, that I wrote because I needed it one day, is now in regular use in three different companies (mine plus two parteners). I get support emails for it to add features or fix bugs about once a month.

If you find it useful, chances are that others will find it useful too.

That said, I think that the Y-Combinator crowd should probably pay more attention to resolving non-programming needs. Most programming tasks already have good tools these days, because if a programmer sees a need, she can code it herself straight away, and programming tasks have lots of programmers identifying programming needs.

For example, I put together a stupid little app a few weeks ago that took a pdf document from Paris Town Hall that lists the addresses of all handcapped parking spaces in Paris. The app reads the list, sends the addresses to yahoo maps to get the long/lat, and then puts the results in a .gpx file for loading into gs devices. Yet another dumb app, but I've had more than 200 downloads of that .gpx file in only a couple of weeks. It's popular because there are apparently few programmers trying to solve problems in the handicapped problem space.

[astrec]

Perhaps better stated that a lot of products did not identify their eventual use beforehand. For your list the seed product had some utility:

* adhesive gives rise to postit * rubber alternative gives rise to silly putty * pedagogic device gives rise to game, kernel

[chaostheory]

"the seed product had some utility"

for some of the seed products their makers intended for them to have utility, but they didn't - that's why they were initial failures...

[cstejerean]

Make it useful to yourself. Solve one of your own problems. Chances are others have the same problem as you.