This short book is packed with sensible observations from the real experiences of a CEO who started a company (Comcate) with a raw idea, raised money, and built the company up enough to have real customers, real employees, revenues, and, I hope, profits (though this last detail is either not confessed or buried in the story and I missed it). The product was a hosted app allowing small towns to manage their “customer” feedback on-line; each town was billed $10K to $30K / year (p. 151). The product eventually morphed into a “code enforcement” package (p. 154) which became their real money-maker. The story is supposed to be more provocative than the usual CEO/start-up story because the protagonist in this one is . . . 15 years old. I actually didn’t find the youth of the CEO to be as amazing as other readers have. The culture of business now permeates teenage life in a way it didn’t when I was Casnocha’s age: Parents are more open about their own businesses, and are more eager to mentor their kids in entrepreneurship. So let me say a few things about how the book might serve a wannabe-CEO or business-founder as a vade mecum.

Because the author is young, he has to get a lot right to be credible. So Casnocha trained himself at finding the right resources, the right examples, and the right books to serve as guides. He knows some things that a lot of business owners don’t learn right away: He knows that his business is all about customers with real problems (p. 21); he rightly disdains utter slavishness to the customer (citing Henry Ford, p. 22), in favor of judicious listening; he determines the price of his product from its cost (p. 24). I could go on and on. Some of his formulations were fresh for me:

“How critical are these problems?” I asked. Some problems only require “vitamins”–that is, a product that’s “nice to have.” Some issues require “antibiotics,” which means they’re mission-critical problems. Most profitable businesses solve mission-critical problems, or the “must-haves.” I learned customer service is not mission-critical for organizations (whereas financial, payroll, and purchasing systems, for example, all are). My product, then, would be a vitamin. At the time I did not fully understand the challenge of trying to sell a vitamin, instead of an antibiotic. This is probably because I personally had no real “needs.” Like most other kids, I had wants, but I didn’t think about needs. Food, shelter, clothes were all taken care of by my parents. I didn’t view the world through a lens of improvement, a perspective all great entrepreneurs carry. (pp. 23-24)

There are a lot of people who want to found businesses who also have never experienced true need.

As I mentioned at the start of the review, eventually Comcate latched on to providing software for “code enforcement,” and he makes a number of astute comments about the difference between “good revenue” and “bad revenue.” Basically, if it scales and can be automated, it’s good. If not, it’s bad. This is hard-won advice, and Casnocha presents the contrast in a couple of pages. (pp. 154-155). A lot of start-ups never figure this out.

On the technology side of the story, Casnocha had a pretty tough time. He always went for the cheap solution, hiring a weak engineer for the first version, and had security and uptime issues (pp. 102-103). Here we have exactly the experience of the non-techie CEO of a web-based business: A missing player in the early game for Casnocha was a good CTO; when he got one, the CTO almost quit: “The technology folks . . . believed the business folks . . . didn’t grasp the nature of the technology. They believed we made too many unrealistic demands regarding what product functionality could be developed and at what cost. The business folks thought the engineers were unnecessarily vague in their time line and cost estimates (’It’s done when it’s done’ always justifiably infuriates managers who need to stick to a budget)” (p. 138). (Clearly both sides here are screwed up when the CTO says “it’s done when it’s done”; perhaps true, but the opposite of diplomatic in a startup.) Reading between the lines, I would have to say, as well, that seeing the CTO as a non-manager is highly problematic in a web-based product. I.e., the CTO should be more of a peer and less of an underling. Casnocha knows some of this, and says: “Technology start-ups take note: when a programmer isn’t on the founding team, it is difficult to find engineers who are both high-quality and affordable” (p. 139). But I think the problem is much deeper, and implicitly you have to read Casnocha as acknowledging that is was a mistake not to have such a founding CTO, because it affects all aspects of the business, not just hiring. In any case, Casnocha must be a good listener, because rather than accept the resignation of his CTO, he got everyone talking again, and made concesssions (p. 140), i.e., reorganized work to fit the engineering mindset.

There are many other good bits; as a teaser I’ll mention the thoughts of a 15-yr. old who wonders why his new COO would haggle over a few extra days of vacation . . . It will be interesting to hear how Casnocha will read his own book in twenty-five years.

Start-Up CTO Bookshelf

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

My Start-Up Life:

Book category: Start-up stories

Impact: 80
Utility: 80
Authority: 85
Good story: 87
Reference: 75
Writing: 87
Humor: 85 (intentional, nut unintentional . . .)
Nudge: 75

Start-Up CTO Score: 82

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:

• Impact (15%): Whether the book changes your mind and/or “sticks”
• Utility (15%): whether the book is genuinely useful for day-to-day consultation
• Authority (10%): whether the author can claim personal experience-based knowledge over the book’s main points
• Good story (15%): whether you want to read the narrative from beginning to end
• Reference (15%): including tools such as a great index, table of contents, associated on-line materials, etc.
• Writing (10%): quality of the writing
• Humor (10%): are there jokes?
• Nudge (10%): this is a gut grade so that a book’s score can be pushed up or down based on intangibles

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