No Vision, All Drive (Book Review) by jgn on Monday, February 25, 2008 in Technology, Reviews, and Startup CTO Bookshelf

David Brown, No Vision, All Drive: Memoirs of an Entrepreneur (2005). $14.95. [Amazon ]

This is a great but odd little book that describes the founding and emergence of Pinpoint Technologies, which created what was apparently the first Windows-based ambulance dispatch software. The odd bit is simply that it doesn't pause to extract its lessons, so one has to, um, think a bit about the story. David Brown starts by being a software guy at the Quebec Department of Transportation. There, he meets a fellow starting a new business selling computer-aided dispatch systems for couriers. Brown learned from their mistakes, and began a circuitous route through a number of companies providing dispatch services to ambulance companies. Eventually he sees the opportunity to create the first solid Windows software for dispatching ambulances. He finds customers, sells to them; and then eventually sells out to a bigger company, ZOLL.

As a story of entrepreneurship, this is long on story and short on sermon. In other words, he tells what he did but he isn't very analytical about it. I guess that's what the title means by "no vision." But let me draw some conclusions from the book. I think he sets out a very reasonable roadmap for founding a startup without taking on any big investors. The recipe is:

1. Know the business. Brown had been deeply involved in a company with a winning DOS product. He already knew the customers and their business. You will read some startup pundits who will tell you not to be captivated by what is already known . . . judging from his experience, Brown is not one of those. While the Windows program was obviously a good one, he had a benchmark in terms of the existing DOS app. So there is no real innovation here, but rather the good timing of needing to satisfy a shift in the market (the need to have a decent Windows app). My takeaway is that there are great startups that are based almost entirely on market timing, and innovation in terms of the core product offering is not required (indeed, it is probably beside the point). I would bet that Brown would in fact see the Windows product as innovative: Reading between the lines of the book it is clear that it was more graphically oriented and that it ran off of a database (first Access, then SQL Server); but, still, innovation is not flogged in the book.

2. Don't quit your day job. The way they (David and one of his two eventual partners, David Cohen) did this was to create a company that sold and serviced the DOS product. This gave them the freedom to cook up their own project. Brown also served a stint worked as the Directory of Technology at a company that used the DOS product. Jumping around gave Brown detailed insights into all of the aspects of running the company. They had some cash from these prior engagements right up to taking new money to get Pinpoint off the ground.

3. Get that first customer. In fact, it was the first customer who trusted Brown from the DOS app period who advanced him the startup funds.

4. Get the right amount of starting capital from the right person. They borrowed $100,000 from that first customer (about $140K in 2007 dollars). Based on the next point, they seem to have taken the right amount of money. Just barely. Brown says they should have asked for $150K. Pitches to banks and the Small Business Adminstration were failures because they had no track record.

5. Get the initial product done fast. They started in September of 1994 and had an alpha in March of 1995 (seven months).

6. Make sure that the initial release provides value right out of the box. Eventually the product became more of an enterprise sale, requiring deployment and customization. But at the start, Brown reports that they had created "a concept called 'RightCAD in a box' to illustrate one of our biggest competitive advantages, the fact that the software was off-the-shelf and didn't need to be customized for each customer" (p. 77).

7. Price your product correctly. It is very difficult to glean the exact details of what was going on in terms of cash flow, but it would seem that there were two people on payroll in the first year (p. 58), at, say, $30,000 each (1994 dollars; monthly payroll is said to be $5,000 on p. 76). On p. 76 Brown says that they made a sale for $25K at an 80% discount, so the list price was, apparently, $125,000. So it looks to me as though a single sale could carry them through a year. The book is incredibly hazy on the amount of time it would take to make a sale, but that seems doable to me. Brown never explains how they figured this out, but I would guess that they were led to the right price by the prior experience with the DOS product.

8. Get the initial team and process right. This information is sort of buried in the book. The way it worked was that David Brown talked to the customers and defined what was to be done; and David Cohen was the leader in getting it built (i.e., writing the code), though it is clear that Cohen had a major impact on the soul of the company, being the person who later on wrote their company manifesto. Brown actually sums up these roles very early on as a way to organize the labor for getting software written, but it will only dawn on the reader later that these are also the two key roles for creating initial value in the company. In any case, here's Brown's statement of the two roles early on at one of the predecessor companies:

I developed a great working relationship with David. As the Center Manager as a reasonably technical person, I knew best what functionality would make our staff's job easier. I fed that information to David, who would implement it. Later, we tried to replicate that environment at Pinpoint by having a product manager who was the expert on what was needed from the customer point of view and a program manager who actually was in charge of implementing the features. The product and program managers had a peer relationship; they had to work together to figure out what was best. We never achieved, however, the rapid identification of issues and the quick definition of features that was possible with the users across the hall. (p. 25)

Amen. So let me draw out some of the lessons here: The product manager is a "reasonably technical person." We do not have here a non-technical product manager. The two managers are peers. And note that Brown sees that the best situation is when the customers are co-located.

Later he describes a software development process that anticipates Agile:

We finally got into an assembly line environment; Bob and I would find the problems and document them in lists. David would take the lists, split them with Eran, and make the fixes. Bob and I would then test the fixes and cross the items off. This went on non-stop for the whole week. (p. 68)

Those the the major elements of the recipe. I've left out of this list all of the jokes, twists and turns, and personal stories. The main story is only 151 pages (there are another 20 with perspectives from other participants) . . . if you want to read a story of how it all came together for one entrepreneur, this is a good read.

Start-Up CTO Bookshelf

I'm going to start "scoring" books that might be suitable for the startup CTO's bookshelf. Below is the grade for No Vision, All Drive. Our main categories for evaluation are:

Each grade is on a 100-scale; 75 is a C, 85 a B, 95 an A, 100 and A+.

No Vision No Drive:

Book category: Start-up stories

Impact: 90 Utility: 83 Authority: 87 Good story: 90 Reference: 75 Writing: 85 Humor: 85 Nudge: 75

Start-Up CTO Score: 84

comments powered by Disqus