3 Things I Learnt After High School About Selling

In between high school and university, I sold my first commercial software, a billing application I wrote back then in Pascal for a banquet organizer in the neighbourhood. Those were probably the most satisfying $10 I had earned. It taught the programmer in me some simple yet invaluable lessons in selling.

1. Know your customers – Before I approached the banquet organizer, I came to know from a nearby shop owner that they were having trouble with the taxman because of improper bookkeeping. I sold the software to them on the very premise that it will relatively improve their billing and reporting capability, and it did.

Here’s a story: A disappointed salesman of a cola company returns from his Middle East assignment. A friend asked, “Why weren’t you successful with the Arabs?” The salesman explained, “When I got posted in the Middle East, I was very confident that I would make a good sales pitch as cola is virtually unknown there. But, I had a problem. I didn’t know the Arabic language. So, I planned to convey the message visually through a poster with three pictures..

First picture: A man lying in the hot desert sand, totally exhausted and fainting.

Second picture: The man is drinking our cola.

Third picture: Our man is now totally refreshed.

And this poster was pasted all over the place. “Then that should have worked!” said the friend. “The hell it should have!?”, said the salesman. “I didn’t realize that Arabs read from right to left.”

2. Price it high – In hindsight, I think I should have priced my billing software higher, much higher. $10 barely covered the development costs, but I didn’t pay much attention to this critical component at age 18. Now I know, it’s easier to lower the price if you’re too high than higher if you are too low. Everyone wants a deal so when you have high prices it’s easy to discount. A high price communicates value. It also helps sustain a higher quality of service.

Here’s a story: We went into Triple A, CSAA in San Francisco. It was going to be our first multi-million dollar customer. I went in with Gina. They loved our stuff, it really was going to do them a world of good. They said, how much is it?

And I was about to go, “$75,000…” And Gina goes, “Shut up I’m the salesperson.” She said, “A million dollars.”

And I went “…” Gina’s going, “Shut up. I’m the salesperson.”

And the guy looks at Gina and said, “Gina you’re out of your mind. We don’t pay more than $675,000.”

And Gina said, “All right. We’ll let you have it for $675,000.”

So, here was this software. I was about to let it go for $75,000, my first professional software salesperson had just gotten $675,000 and she did the same thing. And she said, instead of per year, she said, “But that’s for the base module. What other ones would you like?”

By the time we walked out, we got an enterprise software order for about $1.2 million. The point about pricing is, particularly if you are an engineer, it’s very easy to under price your product. Because you tend to value it on cost or need or competitive or whatever.

3. Personality of the product – My billing app only had 2-3 screens but it did what it was supposed to do. It was quick, it validated all data entry and it had decent exception handling. But it lacked a personalilty. Just like us humans, a product cannot make everyone happy, so it’s important for it to have an opinion and take a side. None of it mattered then, because I was just selling to one customer. But it matters with products now, because there are a few thousand of any sort in the market trying to get the customers attention. So, how do you get the customers attention? Underdo your competitionand make the choice insanely simple for the customers. (Update 26 Oct 2011: Jason Shen has written a nice article about How to Give Your Product Personality.)

Here’s a story: “Professor” Sheridan Simove has “produced” a 200 page book entitled “What Every Man Thinks About Apart From Sex”. This Worldwide Best-Seller is currently sold out online on Amazon. “Author” Sheridan Simove said, “This book is the result of 39 years of painstaking research and practical study into the subject. I left nothing to chance and really threw myself into my work.” The twist — all 200 pages of the paperback book are blank.

Why Writing Software Is Like Engineering

How would you classify writing software? Is it science (as in computer science), a form of art (as in code is poetry or prose) or an engineering discipline? Terence Parr, a professor of computer science at the University of San Francisco, recently wrote about why writing software is not like engineering. Terence concludes that writing software is more an art than an engineering discipline:

Writing software is most similar to writing fiction novels. Writing novels is also an act of creation in an unconstrained and ethereal medium with few well-established construction rules.

I find this notion to be a fallacy, because writing software can be looked as a form of art, but it is largely driven by engineering. Programming can be called a craft or an art-form, but the software itself is not. My biggest argument in this context is regarding automation. Engineering primarily promotes automation of tasks. Most software is written to automate manual or semi-manual processes and enforce computational validations. However, we cannot automate art. A painting won’t automatically self-render itself into a 3D landscape. Nor would the premise of a fiction novel evolve or extend on its own, like refactored source code or OOP libraries can allow for in software.

It has become quite clear in the software world that a big design up-front doesn’t work. Engineering can solve this problem through iterative design and development. Art, on the other hand, cannot be progressive by its very nature. The final result of art is static, albeit beautiful or enjoyable.

Recently I heard Neal Ford talk about Emergent Design during a brown bag session at work. Neal is an author, a speaker and a Software Architect at ThoughtWorks. In his talk, Neal questioned the nature of code? What is software code? I think it’s a subtle yet very important construct in the understanding of software engineering.

A conventional engineer’s output, be it mechanical, aeronautical or any other branch, is the design or the blueprint. The engineer provides the very basis of objects architecture and its inner-workings. But what is the output of a software engineer? Yes, our lot designs architectures too and we also document the inner-workings (as much as some of us hate to). But the primary output of a software engineer is — the code. Hence, software code is the core output of a type of engineering, not a type of art.

To further draw the “art of engineering”, I’ll leave you with an interesting anecdote to ponder on:

Warning! If you still enjoy playing PacMan, don’t read the next paragraphs—they will ruin it forever for you. Sometimes knowledge comes with a price.

Consider the PacMan console game. When it came out in the 1970s, it had less computational ability than a cheap cell phone of today. Yet, it had to solve a really difficult math problem: how do you get the ghosts to chase PacMan through the maze? That is to say: what is the shortest distance to a moving target through a maze? That’s a big problem, especially if you have very little memory or processor power to work with. So the developers of PacMan didn’t solve that problem, they used the anti-object approach and built the intelligence into the maze itself.

The maze in PacMan acts like an automata (like in Conway’s Game of Life). Each cell has simple rules associated with it, and the cells executed one at a time, starting at the upper left and proceeding to the lower right. Each cell remembers a value of “PacMan smell.” When PacMan sits on a cell, it has maximum PacMan smell. If he had just vacated the cell, it has maximum PacMan smell –1. The smell degrades for a few more turns, then disappears. The ghosts can then be dumb: they just sniff for PacMan smell, and any time they encounter it, they go to the cell that has a stronger smell.

The “obvious” solution to the problem builds intelligence into the ghosts. Yet, the much simpler solution builds the intelligence into the maze. That is the anti-object approach: flip the computational foreground and background. Don’t fall into the trap of thinking that “traditional” modeling is always the correct solution. Perhaps a particular problem is more easily solved in another language entirely.

Excerpt from the The Productive Programmer by Neal Ford. Art titled ‘Pacman Apocalypse‘ by Lawrence Yang.

The Lean Wizard of Oz

Recently I read about the yet unbuilt 2011 Ford Fiesta that attracted more than a thousand online pre-orders within the first 6 days of the launch of its reservation program. It made me wonder not only about the marketing hype associated with such campaigns, but also about the fact that pre-orders from such campaigns help dealers gauge interest in the vehicle and what accessories consumers find most appealing.

I found it interesting that the same thought can be applied in the context of technology startups. Pre-release expressions of interest can immensely help Lean Startups gauge interest in the (yet unbuilt) product and what features consumers may find most appealing. It can also help startups ascertain the actual scope, perspective demand and real-world audience of the product, all of which are very important factors for effective monetization. After all, the first goal of a startup is to find those first 50 paying customers.

A big part of the problem is that no one knows what will work with the consumers and what won’t. No amount of market research, case studies or investment will ever substitute a real-world trial. So you start with a bare bones product that requires minimum efforts to build & release for a “preview product”, and hence reduce the time to market.

Building this “preview product”, or a Minimum Viable Product (MVP) as Eric Ries likes to call it, is essentially based on minimizing total time through the Lean Startup feedback loop:

Bootstrapping, rapid prototyping, customer driven development, iterative improvement, eliminating waste (muda), unit testing and continuous deployment are all essential components for building a MVP. Much of this paradigm is also derived from the Toyota Production System.

For example, having a paid account availability notification in your application is a tiny yet nifty approach to a MVP. You build a smaller product, or rather, you build a single feature. You incrementally improve it based on early feedback from interested users. And during this lean startup loop, you measure the actual value of the product by inviting users to pre-order your lean product.

In the field of human-computer interaction, a Wizard of Oz experiment is a research experiment in which subjects interact with a computer system that subjects believe to be autonomous, but which is actually being operated or partially operated by an unseen human being. A related true story I read about an ad-hoc approach, similar to what an MVP can often employ, goes like this:

There was a guy who wanted to sell cars online. But it was a huge system to write from end-to-end, and moreover he didn’t know if it would work or not. So he made a simple website with basic content and forms etc., but he processed the entire back-end work by hand. There was no real automated backend, but the customers got the impression that the entire thing is pretty much automated. This experiment provided him the feedback he needed for expanding his business processes and automating only the essential components.

The best way to predict the future is to invent it.