This is an excellent, concerted exercise in using blogs to build buzz for a product. Based on what I have seen, it’s a good book, and one I’d certainly like to read. Would this work for a lousy book? Depends on the honesty of the reviews and whether people just have to “see for themselves,” as so often happens with films panned by the usual crop of critics.
Just that I know of so far, the book has been mentioned at:
Small Business Trends
Blogcritics in multiple places, here, here, here, and here.
Ship, Then Test. What he means is for a startup to get a product out the door and into customer hands as fast as possible. That way the company can start bringing in money and start getting customer feedback. No matter what he talks about, he always comes back to what I call the first rule of startups: cash is king.
This is the Microsoft way. Get version 1.0 on the market, blemishes and all. Flow some revenue, and keep improving the product. To a point, first to market, or building share as soon as possible, beats the initial version being flawed. Make it flawed enough and this could fail, naturally. Microsoft no longer needs to do this, but one of their strengths is to always act like a startup, alwasy act like the next Microsoft is chasing them and could catch up.
Some of us who were working in Visual Basic support for Microsoft saw demand from developers for a product that would easily port data between versions of Access, and other which ways. When we started the business, the objective was to create products to be marketed ourselves or to sell as a completed concept to another company that wanted to run with it. That would be our first product, called Data XChange.
We got it most of the way done. It was pretty slick, and worked with Access, plus anything for which you had an ODBC driver, and most ISAM databases. As far as we knew anyway, and with a few issues such as not working properly with indexes from one particular database type.
I didn’t do the programming, and barely understood how the magic worked that my colleagues were performing. My job was going to be more in the realm of production and marketing, as well as helping with testing and support. I was chomping at the bit, seeing it virtually done. I even had the crazy idea of approaching Microsoft about packaging it with or marketing it to buyers of MSDN and/or Access. Audacious.
We ended up never releasing it. Not my choice, as my advice then was exactly Guy Kawasaki’s advice now. That was back in 1997. It was a combination of influences. One was the “it’s not perfect and we cannot release it until it has no bugs” outlook. Another was the “we didn’t write it using the latest and greatest object oriented programming and give it an SDK engine that can be used directly in programs by developers, so hold everything, I am going to rewrite it.” The rest was interpersonal issues between us, and differences between the “create products” and “provide services” outlooks on what the business ought to do. Multiple lessons in that, like the need for a coherent strategy, and a buck stopper or firm method of deciding on and sticking to direction.
The compromise was to create a free “Lite” version for download on our web site, while waiting for the rewrite. That handled only Access, none of the rest, by having the other options disabled.
The rewrite never happened, the product never got released, and within a few years was largely obsolete. Following the advice of getting the product out the door would have completely changed the course of our business, if only by providing a modest trickle of revenue and an incentive to rewrite or revise the program with corrections and improvements. And most of the problems or things that could have been improved would never have been a factor for most buyers. I consider this one of our biggest, if not the single biggest, mistakes as a business.
It’s good advice. If you have never been there, it may sound strange, or be difficult to accept it as such. I’ll definitely have to read the book sometime, and not just the buzz.