“>

Many business books have only one good idea. This book has three, which is nice:

1. The business environment is in great shape for early exits – If you want to sell a company for $5-30 million, there are a lot of buyers, they have gotten easier to find, and the deals have gotten simpler. For many more businesses than in the past, an early exit is feasible.
2. Align your exit timeline with your investors to make an early exit possible – If you take traditional venture money, that is a commitment to swing for the fences. It can be very difficult to accept a $5-30 million exit after you have raised even seed money from a VC, because they are depending on your company to consume growth capital and deliver the kind of returns that their funds require.
3. Employ an outside party to manage the exit – The book really drove this point home, presumably because the author is making a career out of this role. It was an interesting perspective to me, not something I hear much about in the blogosphere, and something I’ll have to investigate further.

Unfortunately there were a few problems with the execution of the book:

• Lack of rigor – Peters’s financial models are quite simple, and generally not backed up by broadly sourced data. The traditional-versus-early-exit model that makes the cover of the book and drives home the point about avoiding VC is purely hypothetical numbers, for example.
• Canadian heavy - Writing about what you know is great, but more information about key geographies like the United States would have helped make the book more credible. There is plenty of research and statistics available, and the author only scratched the surface.
• Simplistic Angels versus VCs viewpoint – There are a lot of opinions flying around about what makes someone a super-angel, or what makes a seed-stage VC firm. Suffice to say the book’s black and white distinction between angels and VCs is simplistic. I would have expected more reasoned discussion of investor types, given that investor alignment is a key point.
• Insufficient detail – The later chapters in the book, notably around pricing, are insultingly light on detail. I realized that pricing is complicated and it’s best to work with a professional, but that’s no excuse for introducing net present value of cashflow and then leaving everything else as an exercise for a consult.
• Too much of a commercial – I understand that the point of this book, and many others, is to promote the author’s services. However, there were too many pages dedicated to the need for such services, and too few to the nuts and bolts of what would be done or how value would be realized. That, in the end, is the real problem with this book. I was hoping the author would tell me more of what he knows, since I’ll probably never have the opportunity to hire him directly.

The author has a blog (angelblog.net), and it remains somewhat unclear to me why he put the effort into a book rather than sticking with the blog format. Much of the information in this book is available on his blog and around the blogosphere. I had been hoping for more new work, or more depth. Unfortunately I did not find it.

If you’re considering starting a company with an eye to early exits, it’s easier to read this book than to track down 100 good blog posts on the topic. Unfortunately, you’re going to need the blog posts either way to fill in the gaps.

Read on for more detail…

About 6 months ago, I bought a used Sony Portable Reader from a friend of a friend. I travel a lot, and have a lot of open-format stuff I wanted to read (pdfs, html manuals, etc). I’ve always through electronic ink was interesting technology, and buying used appealed to my cheaper inclinations.

Fast forward to a a month ago, and having an electronic book has changed my life. The Sony fits in my bag nicely, reading it is quite pleasant, and I can easily carry 50 books with me at any time. It has changed the way I read, allowing me to have several books going at once and switch between them based on my mood, something I used to do in high school. libprs500 (now Calibre) is pleasant to use on the mac and open source. I even used the Sony software to buy a few closed-format bestsellers at reasonable prices.

Unfortunately, my Reader broke, possibly due to it’s previous owner or just due to being dropped. It will no longer hold a charge or boot properly. I took it apart, following helpful Flickr directions for prs-505 disassembly, but to no avail. If anyone has a project that would benefit from the eink components, which seem undamaged, let me know.

Since I have a vacation coming up, and I’d so enjoyed the experience of having one, I decided to replace it. And being a consummate gadget shopper, I went looking for other options. I settled on the Kindle as the most advanced option, attracted by it having internet access and a way to buy and load books that would require Windows. So I went ahead and primed one.

I received it the morning I left for a trip to New York on Acela. This gave me some time to get started using it. My first reaction is that it is really bulky. It barely fits into the pouch of my laptop bag, while the Reader is about the same size as the Moleskine I keep there all the time. The Kindle came with a leather cover, but it doesn’t really fit into it well, and that just ads more bulk. The cover has a big elastic to hold it closed The on/off switch is on the back, where it is blocked by the cover. In contrast, the Reader has a cover that clips on, is held closed by magnets, and a switch on the top that is easy to access.

The Kindle could survive all these misfeatures, if the reading experience were good. It is not. I don’t know how they tested this thing, but anyone with normal sized hands can’t find a way to hold it without accidentally hitting buttons. They claim it can be held with both hands, but I have to rest it on a surface, or hold it gingerly with my right hand only. The big fear of the designers seems to have been that people couldn’t find the next page button, so they made it take up one whole side. A second next page button and a previous page button consume the other side. Which means if you want to hold the book naturally in one hand, you are going to accidentally palm those buttons, and lose your place.

The keyboard, which is necessary to make the buying and web experience possible, also takes up a lot of space on the device and risks accidental key presses. There is really only one point on the front of the device you can safely rest your thumb. And holding the same position for long periods of reading isn’t any fun.

On the bright side, the EVDO is a cool feature, and I like the idea of devices that come with infinite bandwidth. The scroll-wheel menu interface is also good, certainly better than the Sony ten-button menu interface. But these don’t make up for the difficult reading experience. And with a new iPhone coming, I’ll have a portable web browser anyway. I just need my electronic book to be a good book, not a digital convergence device.

I’d love to see a better E-Ink book than the Sony Reader. But the first generation Kindle is certainly not it. Don’t buy one.

Most new products fail to succeed. They fail because they are not adopted by customers. Adoption generally fails because users don’t change their habits to use or purchase the new device or service. People generally avoid change. Creators and purveyors of new products must find a way to motivate change. The focus of this book is on how to understand when users are willing to change.

The Change Function states that the willingness of users is a function of two parameters: Crisis and TPPA. (Readers with mathematical ability will have to forgive Coburn’s limited grasp of mathematical notation and terminology). Crisis is a motivating event or condition. Without Crisis, people will keep doing whatever they have been doing. TPPA is Total Perceived Pain of Adoption, which is a good phrase. This is how difficult people expect that the change will be, which is only tangentially related

TPPA comes in many forms. The most obvious is price. But generally price is not most important. More important source of Pain might be the need to learn new things, or the possibility of the system not working out and leaving the buyer feeling stupid. Pain comes from political or career risk. And pain comes from fear of the unknown.

Crisis can also vary. The crisis for purchasers of HDTVs or iPods is a fear of being left out. The crisis for some iPhone purchasers is a need for “internet in my pocket”. For others, the iPhone is a way to purchase coolness. Regulatory changes can drive a crisis, for people or businesses. So can life changes, like a new baby.

TPPA can be lowered. Improving usability reduces TPPA. Try-before-you-buy is another popular technique. Allowing users to start small and build up confidence reduces their risk. Initial user experience should deliver minimal pain. And the perception of pain must also be managed, through marketing. If users think the product is difficult to use, or prone to breakage, or many other intangibles, these can be managed with appropriate messaging.

Crisis can be created or discovered. Marketing to CEOs can create a crisis, if they fear their company is being left behind. Marketing to individuals can create desire for a new experience or new device, a kind of crisis. Crisis that already exist can be exploited by modifying the product to address them. Finding a motivating Crisis is how many products that were “before their time” become mainstream. A killer application is often a kind of crisis.

Users (generally unconsciously) weigh the TPPA versus their own Crisis. This sounds obvious, but is pretty fundamental stuff. It means, for example, that If You Build It, They May Well Not Come. For developers of new technology, from eBook readers to programming languages, ask yourself what the motivating crisis is for your users, and whether it exceeds the TPPA. If it does, you need to find different users, create Crisis, or lower TPPA.

Jesse Vincent just shared with me a
copy of their book
href=”http://www.amazon.com/exec/obidos/ASIN/073571410X/innocuousorg-20/ref%3Dnosim/104-5794965-3152724″>De
fensive
Design for the Web: How to Improve Error Messages, Help, Forms, and
Other Crisis Points. It was a very quick read this morning
before breakfast, and I think also worthwhile, even though I am not
currently a builder of real webapps. I find well designed web
applications interesting, and like learning more techniques for doing
it. This book is mostly about user-level guidelines, rather than
technical detail. But that is important too, since when building
technical frameworks it is important to enable the right kinds of user
interaction.

The book is pretty good. It gives a set of 40 guidelines with real
examples of sites that break and sites that follow the guideline. The
guidelines mostly focus on what to do when something goes wrong or how
to keep something from going wrong. The core idea is that when looking
at the usability of your website, the error cases are as important as
the non-error cases.

One area in which I disagree is their support of restrictive forms.
They encourage sites to prevent users from entering incorrect data
through the use of drop down lists (for things like states or dates)
and client-side validation with JavaScript. The principle is that if
you keep users from ever entering bad data, then you are sure they
won’t have a confusing experience fixing errors. I tend to find that
these restrictive forms harm my user experience more than they help
though. I’d rather type a free-form address, or phone number, or date,
and be corrected, than have to mouse- or arrow-around in 6 drop down
lists to enter two dates.

Combining client- and server-side validation of form data is an
interesting challenge for framework development. Is it possible to
easily combine these so that site developers don’t have two divergent
code bases (most likely in different languages) to maintain?
Consolidating this functionality probably requires JavaScript code
generation, so that the server-side encoding of the validation rules
can be pushed down to the client. I’m not aware of any JavaScript code
generation that really makes for a usable system, so maybe this idea
would be doomed anyway.

Because it ignores technical details and focuses on user experience,

href=”http://www.amazon.com/exec/obidos/ASIN/073571410X/innocuousorg-20/ref%3Dnosim/104-5794965-3152724″>De
fensive
Design for the Web is a quick read. It’s guidelines are not
perfect, but they are reasonable. It presents you with a helpful
checklist which can be used to improve your crisis points, and thus to
improve your sites whole user experience. And it is lightweight enough
you can throw it at a coworker without be charged with assault. I
recommend it for people doing webapp development.