The current book narrative is very naive. The answer to the question "What Are the Elements of A Successful Startup?" is hardly in the idea alone.

This is a common pitfall that plagues most developers who want to become entrepreneurs.

The idea is only one among several important factors that lead startups to success: timing, competitive advantage, finding the right product-market fit, identifying customer acquisition channels, devising creative ways to get the word out (aka viral loop), testing hypotheses early on, etc.

The number of startups with awesome ideas that have failed because their founders ignored all other variables is too large to ignore. Of course you don't hear about those as much, because (surprise surprise) the media feeds off success stories.

Please don't help propagate the idea myth.

Maybe I didn't communicate this clearly enough in the copy of the site, but my aim isn't to solely concentrate on ideas. The aim of the text will be to find common patterns between successful startups in their ideas as well as their execution that can be applied to other projects. I hope that clears things up a little bit.

Cool, I thought I'd give you a heads-up. Too many programmers make that mistake, so when I saw an idea-centered narrative in your .docx a red flag came up.

Yea I agree. I started by focusing on the idea just because it seemed like a logical first step, but that's by no means the extent of what I want to do with it.

I'm not sure which part of "patterns" or the book description suggests it's only about ideas, but in general, patterns can be about process or anything else. Where there are useful solutions to recurring problems, there are patterns worth mining and recording.

I might suggest the project just call these "startup patterns" as "design patterns" tends to make people think of technical coding or software architecture patterns. "startup patterns" is deliberately open-ended.

> I'm not sure which part of "patterns" or the book description suggests it's only about ideas

The .docx book is all about ideas. The author admits that.

Why not call it Startup Patterns? "Design patterns" has a bad ring to it for a lot of hackers and startup people. "Startup patterns" is shorter, captures the basic idea, and is less constraining. Besides, most startups aren't designed.

Edit: I just noticed http://news.ycombinator.com/item?id=2746291. It must be obvious!

Edit 2: I would buy and read this book if it were done a certain way: if you avoid overgeneralizing or even interpreting what people do. If you could observe similar things that, say, three or more successful startups have done, and simply report them, that would be very interesting - much more interesting than trying to build any model or theory out of it. Basically, I'd like to read something like anthropological field work among successful startups; the more descriptive and less prescriptive the better. Practices that seem odd or irrelevant, and yet crop up several times, would be of particular interest. So would examples of things that successful startups do in opposite ways.

The reason I say this is that startups are not well understood, yet everybody seems to want to prematurely generalize them. These generalizations are not of much interest. More concrete observation, however, would be.

Edit 3: you should also find out what things startups do that they've always done from the beginning, versus what things got added later.

+1 especially to 'more descriptive, less prescriptive'. And I wish there was a way to include what the interesting unsuccessful/less successful startups did.

Interesting idea. Instead of a Word document you might want to consider writing the book in plain text, HTML or LaTeX. This will make it a lot easier to merge in changes from other contributors.

Good Idea. I'll do that now.

Hard to get to the text but good ideas once you do.

Rather than just diving into pattern descriptions, you may find it useful to agree on a corpus of successful startups and then identify specific things they've done well. Once you have a list of these things, you can start to cluster them together - pattern recognition!

This is roughly the process I've used in building pattern languages on the past. I'd also suggest you have a good idea of what you mean by success, because this is the filter through which you'll identify what's worked well. In other words, patterns should be opinionated. And that's going to be non-trivial (but tractable) in a project with multiple contributors.

This is clearly not the first open-source book, and not even the first one hosted on github. See https://github.com/schacon/gitbook for instance.

Good find. I didn't know of any personally, and couldn't find one after a Google search, but I'll take the claim off the site now.

This is pretty cool - but it's hard to get to the book content itself. Maybe consider just publishing it as blog posts?

Or a jekyll site via github-pages? (easy fork-and-pull for contribution)

I've never heard of jekyll but I'll definitely look into it thanks :)

I just found out about jekyll too, very interesting. If anybody else is curious https://github.com/mojombo/jekyll/wiki

Yea I definitely think that's an option. I really like the idea of getting the community to collaborate on it too though.

i would of much preferred you submit this when there was some content or more thought out. There's not even anything to look at. You should of at least maybe brainstormed out your ideas further with a table of contents or further list of ideas for content you intend to write or want people to contribute to. Theres nothing to show here.

Why not write it in Markdown, makes for easier reading on GitHub and provides the possibility to parse and publish later on.