The myth of the 7 day product
Recently, I wrote about the concept of building a product in 7 days. After writing it, I started on such a project and am now on day 6. In doing this, I learned a lot about a whole list of "Things Not To Do." Along the way, I’ve decided that there’s some mythology around the quick project, which I’ll give more detail on below.
A well executed 7 day project has the following components:
- Basic idea or assumptions that have been mulled over for weeks
- Very casual market testing by pitching it to friends over a drink or two
- Spontaneous development over a weekend or two that leverages well-known libraries
- If the libraries aren’t well known, perhaps you tinkered with them in the past, which perhaps even inspired the idea
- 100% viral growth opportunity without major marketing required
A poorly executed 7 day month project looks like this:
- Initially, an unknown market and an unknown target audience
- Zero data on market potential – you’re just making assumptions about someone else
- Significant planning and development that concretely incorporated misguided assumptions
- Heavy of use of undocumented, complex 3rd party libraries that cause major debugging hassles
- Marketing growth that involves significant business development and capital
Examples of quick projects done well
Under these specifications, well-understood closed-system websites are the best types to build. That’s why sites like Facebook, eBay, Craigslist, Digg, etc., are all fantastic projects to write quickly. You don’t have to build a significant amount of technology other than forms and database tables, and the mechanics to put in and remove data. You don’t depend on complex libraries to put things together – in some of those cases, something like PHP is the fast way to throw ideas together.
As soon as you start adding things like importing RSS, or transcoding video, or crawling the Internet for data, you enter a realm where you start incorporating potentially faulty libraries. And as many programmers know, you can easily spend a day trying out and throwing away lots of different libraries and hit bugs that really aren’t your fault. This chews up days in your schedule.
The role of audience in developing products
An especially hairy problem is when you are developing for a different audience than yourself. Then you run into a situation that you might spend the entire 7 days really trying to understand people, and never get to the point where you’re shipping product. You end up making assumptions, writing code, and then iterating over and over again, without really figuring out what people want. This is the most dangerous case because it’s "upstream" from everything else – you could do everything else right but still be required to rewrite the entire concept.
Like this post?
If you liked this post, please subscribe or follow me on Twitter. You can also find more essays here.
-
Craig Hubley
