

Show HN: Design Patterns for Startups - dshipper
http://www.designpatternsforstartups.com/

======
arturadib
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.

~~~
dshipper
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.

~~~
arturadib
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.

~~~
dshipper
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.

------
gruseom
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.

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

------
sashthebash
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.

~~~
dshipper
Good Idea. I'll do that now.

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

------
mmahemoff
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.

------
a3_nm
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.

~~~
dshipper
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.

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

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

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

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

------
angryasian
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.

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

