Tag Archive for 'Strategy'

How to Annoy People

Published
by
Victor Nicollet
on December 6, 2011
in Strategy
. 0 Comments

Here is a hypothetical situation :

The kingdom is in trouble, and the King must enact a new law. Of course, such a law will make many people happy for years, but some people will be annoyed by it for a few days. He has two possible choices :

Law A will make 20% of the people happy at the cost of annoying 1%.

Law B will make 90% of the people happy at the cost of annoying 10%.

Which law should the monarch enact ?

This is not the kind of problem that engineer types like me enjoy — no matter how much we try to abstract away the details and build a sound foundation for that decision, some ethics will inevitably seep in.  Is it right to annoy an additional 9% of the people so that 70% more people become happier? Where do we draw the line in term of percentage, and in terms of annoyance — a few days might be fine, but what about a few months or years?

As you might expect, this is not an entirely hypothetical exercise. It is, in fact, the very core of the opt-in versus opt-out debate. Above, law A is opt-in : only 21% of the population knows about its effects, but at least there will be very few complaints ; law B is opt-out : it ensures that 100% of the population knows about it, but it will annoy the 20% who will have to manually opt out.

My start-up hosts discussion forums for associations. Every one of our customers has faced the same decision : should they send an e-mail to their association members telling them « please come and sign up on our forums » or should they import their member directory and let naysayers unsubscribe ?

With the opt-in approach — please come and sign up — the initial e-mail is followed by a small number of sign ups, usually from the more active or dedicated members, and will be ignored by everyone else. If the number of initial adopters does not reach a critical mass, the forums will simply die off and be forgotten by everyone.

With the opt-out approach — import all the members — everyone will be notified every time a new message is posted, as would happen on a mailing-list. A forum message from a friend is a lot more interesting than a « please come and sign up » e-mail and drives more members to connect and participate. The critical mass is reached far easier (and faster!) and the forum becomes an essential part of the community. However, those who did not wish to participate will receive e-mail that is literally unsolicited, and they will complain about it — while the number of active users increases significantly, the number of complaints and unsubscription requests increases even faster. The delicious irony of it all is that the number of complaints is driven up because the communication tool helps those annoyed members find each other and speak up in unison.

Before continuing, let me fend off two possible problems.

First, the opt-out approach is not intended to be a sneaky trick — we always strongly advise customers to send a preliminary e-mail to all their members in advance, telling them about the plan to move to a new discussion system. Not only does it keep things civil and honest, but people who absolutely hate receiving messages from their community can ask to opt out before it is too late. Online communities have trouble blooming when 10% of the messages are complaints about the very existence of the community, so it is in everyone’s interests to keep naysayers out.

And if anything else fails, we can wipe out members from our system on demand.

The second problem will be familiar to readers of Seth Godin — permission. Through the eyes of a permission marketer, to import all  the members without their prior explicit opt-in consent is absolute heresy.

I find this view a bit too extreme. Well, it does make sense when trying to sell things that 99.99% of the people will not care about, such as viagra or cheap hotels in Bangkok. But members actually care about what is going on in their association, and — based on our experience — only a minority of members ever asks to be completely removed from the forums. Most members only unsubscribe from individual discussions that they do not care about, and choose to remain available on the forums as a whole.

It feels sad that so many people would miss out on a great experience just so a handful of curmudgeons can spare the effort of clicking an unsubscribe link.

Back to the point.

As far as I can tell, the approach that helps most members get involved in an online community is :

  1. In advance, send them an e-mail telling them that the association is about to move to another online community system — in our situation, it could be described as a mix between a forum (for those who wish to be very active) and a mailing-list (for the occasional participants) — and that each of them will receive those communications on an opt-out basis.
  2. You will receive messages saying « this is a bad idea » or « I don’t want to receive those communications » and you should take steps to make sure that no person who opted out at this stage is ever imported into the forums. Unless they ask for it later, anyway.
  3. After enough time has passed — at least 48 hours for large associations — import everyone into the forums, and write a welcome message there explicitly asking them to say hello when they reach it for the first time.
  4. If any other people request to be completely unsubscribed, you may simply remove them from your forums and they will stop receiving messages. If you need to absolutely make sure that all their data has been wiped from our database, drop us a line and we’ll take care of it for you.

We have had several customers build a thriving online community for their association with this approach, and have even seen a few « get me out of here » naysayers change their minds and come back online, once they understood everyone else was using it.

Where do you stand on the matter ?

Article image © Carlo Piana — Flickr

The Three Components of Negotiation

Published
by
Victor Nicollet
on November 10, 2011
in Strategy
. 0 Comments

We negotiate several times a day, even if we do not recognize those occurences as such — « accept or walk away » is a fairly instinctive, if somewhat inefficient, negotiation strategy, and it goes hand in hand with the modern « take it or leave it » strategy employed by most mass consumer shops.

What is negotiation anyway, and why does it happen?

It happens because when humans cooperate, they get a cake that is bigger than the sum of its parts, and they need to decide how to split it. For instance, if I grow potatoes and you breed cattle, we could decide to put together my delicious Désirée tubers and your tasty Charolais steaks, which is a big improvement over otherwise potato- or beef-only diets. And then, we would argue over how much of the final mix each of us would get:

ME: We both contributed equally, so let’s get 50% each.
YOU: Breeding cattle is harder than watching potatoes grow, so I want 65%.
ME: Suit yourself, I know a guy who only asks for 55%.
YOU: Fine, I’ll go as low as 60% because I like your blog.
ME: I just told you I know a guy who…
YOU: …and that would save you the effort of finding that guy before lunch.
ME: Right. 60% it is, then.

You were a good negotiator, so you managed to squeeze 10% out of this. What happened? Let’s break this down.

Irrational Arguments

« We both contributed equally » might be true. Maybe I spent as much time growing my potatoes than you spent working in your ranch. But that is not my argument. What I have written between the lines is that it is fair for equal efforts to receive equal rewards.

And fairness is not a rational argument. It is a subtle way to circumvent rational thinking and aim for our unconscious ethical programming and, by definition, make decisions that are not in our best interest. In the eyes of a good negotiator, this is a loophole to be exploited.

There are many other such loopholes in the human mind. My favorites are:

Reciprocity is an atavistic impulse to give back whenever we receive something, even if that something is mostly unrelated to our objectives. In the example above, going from 65% to 60% is cleverly framed as a gift instead of a simple acceptance of my terms, which makes me unwilling to further haggle over whether it should be 57.5%.

Imprinting is our tendency, when we have no idea how much something is worth, to go with the first guess, clue or hint that we find about it. By suggesting a 50-50 trade, I imprinted you on the idea that potatoes are about as valuable than meat, and this serves as a basis for your « reasonable » 35-65 counter-proposal instead an extreme trade like, say, 3-97.

Guess what the market rate for potatoes and Charolais steak is? 3-97. I would like to correct my previous sentence:

You were a good bad negotiator, so you I managed to squeeze 10% 37% out of this.

And then, there’s a slew of emotional manipulation that does not appear at all in my example above. You can feign disappointment to try and get more out of a deal — “I really hoped you, of all people, could get this done for me.” You can pretend to be offended, shocked or angry in order to cause a large shift in the terms being negotiated — when you haggle in a bazaar, quote a price that is too low and you will be told that it is insulting, and kicked out of the store.

There are many other examples. Go read this blog article and read Predictably Irrational by Dan Ariely.

Rational arguments

You might expect this section to be as rich as the previous one, but it is not. There are only two different rational arguments you can say in a negotiation: “I will  not accept this outcome because [credible reason]” and “You will accept this outcome because [credible reason]“. Let’s examine our conversation with this convention:

ME: Suggests 50-50
YOU: No, because [breeding cattle is harder than watching potatoes grow], suggests 35-65
ME: No, because [I know a guy who only asks for 55%]
YOU: Suggests 40-60
ME: No, because [I know a guy who only asks for 55%]
YOU: Yes, because [that would save you the effort of finding that guy before lunch]
ME: Accepts 40-60

This is the reason why the most fundamental principle in negotiations is be willing to walk away. If you cannot or will not walk away, and the other guy knows this, then you can no longer say « No, because » and this cripples your ability to negotiate properly.

Typical reasons why I will not accept an outcome:

  • The costs are greater than what I get out of it. Maybe I’ll ask for more money, or non-financial benefits (exclusive rights, free advertising…)
  • It’s too risky for me. Maybe I’ll ask for insurance, or add terms to our contract that provide me with acceptable protection.
  • I can get a better offer elsewhere. You can either match that offer, give me something I cannot get elsewhere, or give up.

Typical reasons why you should accept an outcome:

  • There are additional benefits you did not take into consideration, such as not spending the time to find a better offer elsewhere, or my goodwill in terms of future trades, or my reputation as your client/provider.
  • If you do not accept now but change your mind later, I will not be able the same offer to you again in the future.

These reasons do not have to be true, they only have to believable. I don’t know anyone who would accept a 45-55 split on potatoes and Charolais steak, but you don’t know that, so I can still bluff my way through our negotiation, bringing you down from 65% (which is still a 32% win for me) to 60%. If you knew that no sane person would accept a 45-55 split, you could certainly call my bluff and even bring me back up to 10-90 or so.

How you present those arguments is a matter of style. Here are four different ways of presenting the same argument (you will not get more than $30k for an APL job) :

  1. No one else in town hires APL developers like yourself, so you either accept this $30k job or get out.
  2. I am certainly interested in your APL skills, but I would be losing money if I paid you more than $30k.
  3. We are looking to fill our APL development position, but I am not at liberty to offer you more than $30k.
  4. We have interviewed several candidates with your skills, and most of them are below your wage requirements.

Some aggressive types would prefer approach 1, while manipulator types would go with 2 (which is a lie), passive types would hide behind a third party authority using 3, and sneaky types would try to get an even lower salary quote by withholding the $30k figure in approach 4.

Alternative Benefits

This is a subtle but essential part of many successful negotiations. It’s not only about the money. In the above example, I traded 5% for the ability to get my food in time for lunch — a concept that had not been mentioned at all before. You decided that instead of matching my requirements as I expressed them, you would offer me something that was unexpected and which, to you, cost less than 5% but still, to me, was worth at least 5%.

Going down alternate routes is an excellent way to get a stuck negotiation moving.

Article Image © William Neuheisel — Flickr

Having a Strong Opinion

Published
by
Victor Nicollet
on September 1, 2011
in Imperative
. 0 Comments

Many blogs about technical hiring will at one point state something about buzzwords and programmer flexibility. One of the original trendsetters, Joel Spolsky, said:

The recruiters-who-use-grep, by the way, are ridiculed here, and for good reason. I have never met anyone who can do Scheme, Haskell, and C pointers who can’t pick up Java in two days, and create better Java code than people with five years of experience in Java, but try explaining that to the average HR drone.

And this is not only a point about elite languages like Scheme-Haskell-C versus mundane languages like Java-PHP-whatever : flexibility, the ability to switch languages and to adapt to new interfaces and libraries, is almost always presented as a prerequisite to being competent. John can perform miracles with PHP but cannot easily learn Ruby ? Then John is not a competent programmer, he is just a competent PHP programmer.

Maybe there is some truth to this characterization. Maybe there is indeed something about good programmers that lets them shine in a language-independent way, with languages as mere details of their day-to-day miracles. But I am vaguely uncomfortable with that notion. And not for personal reasons — my current language of choice is one of those elite functional languages that would hypothetically place me at the apex of the competence food chain.

I believe the critical element of programming competence is not ability but passion. What makes you a good programmer is how much you care about software development. Does John have a nine-to-five PHP programming job and hardly touch the computer outside of work, or does he do small projects on the side, or contribute to Open Source PHP software, or answer technical PHP questions on Stack Overflow, or perform any other number of PHP-related activities that do not have professional rewards as their main objective? Does he unconsciously try to do the right thing in his code, even though it will be harder than writing a dirty hack to make his boss happy?

I have seen people, many of them high-ranking academics, with the intellectual firepower to outgun me in any programming-related endeavor, but a striking lack of passion that let their applications crippled, hideous and unreliable. And I have no doubts that, had they cared about those things, they could have done better.

I have seen people, many of them students, with a genuine passion for software development, who would spend their free time hacking together video games or dynamic websites or clever hacks, who would notice after a while that their abilities were stagnating and, unable to improve, would give up programming rather than live with the frustration of writing software worthy of their expectations.

And when you care about programming, you tend to have strong opinions about how it should be done.

Some of these opinions are trivial. My hair stands on end whenever I have to read badly formatted code — I don’t care about the opening-brace-position flame wars, any convention is fine by me as long as it is consistently followed — and the authors often wonder why I would care about such a silly thing. I have a strong opinion about how code should look like, and I dislike working with people who do not share that opinion.

Yes, I am one of those Scheme-Haskell-C elite programmers, and I can pick up Java in a few days and outperform experienced Java-only programmers. I have done it several times in the past. And every single time I did so, I felt dirty and miserable, because Java goes against several of my opinions about what software development should be like.

In fact, I am not really surprised about the popular success of Python and Ruby on Rails — not in terms of how many projects are written, but in terms of how outspoken the technical advocates are. This is because those two have something that appeals to people who can become passionate about them : a clean core philosophy you can agree or disagree with.

Python zealots flock around the Zen of Python :

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one– and preferably only one –obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let’s do more of those!

Ruby on Rails fanboys have a similar set of core beliefs, the Rails Way:

DRY – “Don’t Repeat Yourself” – suggests that writing the same code over and over again is a bad thing.
Convention Over Configuration – means that Rails makes assumptions about what you want to do and how you’re going to d o it, rather than requiring you to specify every little thing through endless configuration files.
REST is the best pattern for web applications – organizing your application around resources and standard HTTP verbs is the fastest way to go.

So, if you happen to wholeheartedly agree with the Ruby on Rails way, then by using it you are certain to find both a technical environment in which you can feel happy, and a community that shares you strong opinions about software development. It is any wonder, then, that people passionate about the RoR values would flock to RoR and, inevitably, start advocating its use?

Going a little bit further, if you are hiring for your software company, would you rather hire someone with weak opinions on most topics because they are «flexible» or someone with strong opinions that match the strong opinions of your company? Given the choice, I would certainly hire the latter.

I have my own «core philosophy» that I apply to the way I write my own code. These would be, by order of decreasing importance:

  1. It is better to have a correct program with few features, than a buggy program with many features.
    If possible, take the time to design your code and your interface so that errors cannot happen. If not, explicitly detect and display all errors as they happen. If possible, have a programming language and a programming style that can eliminate by design many errors, rather than a programming language or programming style that improves productivity at the cost of having more errors.
  2. It is better to prove the correctness of a program, than to test for the existence of bugs.
    Tests cannot prove that the software is correct, they may only prove the existence of bugs. A proven program contains no bugs, there is no worry about having enough code coverage and enough test cases. This is a special case of “fail early” : better to fail at the compilation stage, than to fail during tests or at runtime.
  3. It is better to accept that code will have to be rewritten, than to future-proof a complex design.
    Future-proof code will likely be larger, and contains more untested pieces, than normal code. This increases the probability of bugs, without completely eliminating the possibility of a completely unforeseen design change that still involves a rewrite. Preparing your code for a rewrite, by splitting it up into clean independent self-documenting modules and creating automated correctness checks for these, is the best way to make it flexible.
  4. It is better to enforce data constraints through types, than to enforce it through code.
    Attempting to store data that violates the constraints fails earlier if the type cannot represent that data, especially in a statically typed language. Doing things this way might take longer than just keeping a flexible data type and performing the constraint checks in the code, but the odds of it being correct are higher.
  5. It is better to have the computer do work for you, than for you to do that work yourself.
    Why write trivial unit tests when you can harness the type system to perform those checks? Why define or configure things by hand when your framework could define or configure them for you?
  6. It is better to rewrite your code using new concepts, than to insist on using existing but ill-adapted concepts.
    Concepts improve productivity and readability, and by design will prevent some kinds of incorrect usage, but only as long as they match what the software is expected to be doing. Otherwise, at best they will be a useless weight and at worst will have to be tediously worked around to achieve anything. The size of the refactoring is no obstacle: if half the application needs to be adapted to the new concept, then so be it.
  7. It is better to repeat yourself from time to time, than to introduce too many concepts.
    Any repetition can be eliminated by adding a new abstraction through refactoring. That abstraction is usually a mere application of an existing pattern or concept, but might sometimes give flesh to a new concept. While that concept arguably already existed in the non-refactored code, it is easier to understand uncommon concepts by looking at their repeated code, than to give them a sufficiently understandable name.

I don’t know. Maybe someone might agree with me one day.
Article image © Timo Newton-Syms — Flickr

Software Patents – Why, Why Not

Published
by
Victor Nicollet
on June 2, 2011
in Strategy
. 1 Comment

Intellectual property exists for a reason: protecting creators from the theft of their creations. Not in the sense that the idea is stolen — idea theft would imply that the original owner would not have access to the idea anymore — but rather that the opportunity to monetize that idea is stolen or destroyed by someone with the industrial and commercial firepower to completely take over the market. Georges Méliès created the 1902 motion picture Le Voyage Dans La Lune, which was a special effects masterpiece at the time, but was denied the opportunity to monetize it in the United States because of piracy and eventually went bankrupt. The question asked by intellectual property supporters is, would people invest time and money in creating new motion pictures if they knew the same thing could happen to them? Copyright is intended to ensure that, if someone runs with the author’s work, the author can shut them down or make them pay.

The same reasoning exists behind patents: inventors spend time and money on the arduous process of elaborating and perfecting new machines or processes. Then, he starts selling the invention, and inevitably, other people and companies will notice. People and companies that did not participate in the elaboration, that have a better manufacturing infrastructure, a better sales network, and are not weighed down by the cost of researching the invention in the first place, so they can easily manufacture and sell the invention, outmatch the inventor on the market due to lower prices and larger quantities, and keep the profit to themselves. But if the inventor holds a patent, he can force the rogue manufacturers to pay him for his invention.

Perhaps the single greatest example of modern patents is the pharmaceutical industry. The cost to creating a new drug is tremendous, not because thinking of new molecules is a strenuous activity, but because of the many clinical trials required to turn tens of candidate molecules into a single FDA-approved doctor-prescribed drug. But once the drug exists, competitors can find out its composition at a fraction of the original cost (after all, the composition is published as part of the approval process), manufacture it, and sell it at a price that does not need to pay for the original research and development. Were they allowed to do so, one would expect the pharmaceutical innovation to freeze in a prisoner’s dilemma as stealing the drugs of others is far more profitable than inventing your own.

Patents work in these traditional industries for two reasons:

  • Inventing the patented mechanism or creation is a costly, arduous process, but creating a competing product based on the invention is comparatively cheap. This means that without patents, copying is more profitable than inventing.
  • Two people inventing the exact same thing without hearing from one another is extremely unlikely, either because the inventions are so esoteric and unusual that no two people would reasonably think of the same thing, or because the inventors are part of a community of experts that regularly hear of what the others are working on.

Software patents protect algorithms — processes executed by computers to transform data and interact with humans and other computers. The problem with patenting software is that the two reasons above are the exception rather than the rule.

Creating competing software products is hard. Assuming that Microsoft invents a wonderful new algorithm and includes it in Windows 8 without patenting it, simply reusing that algorithm does not make the creation of a serious Windows 8 competitor any easier. The modern software industry is so complex and multi-faceted that the reuse of any algorithm, no matter how clever or innovative, would not contribute significantly to the creation of a competing product. Copying over a single algorithm does not grant your competitors access to your network of compatible software, your corporate partnerships, your user base, your software development infrastructure, your reputation, your existing maintenance contracts, or any of the many other ways in which the average software company turns an algorithm into money.

And there’s more. The job of software programmers is to create new algorithms, and there are quite a lot of software programmers around. Hundreds of thousands of software programmers. This means that any algorithm which happens to be a slight modification or adaptation of an existing known algorithm, or the result of a deterministic problem-solving strategy, has already been invented at least a dozen times, currently sleep in a legacy project somewhere, and will be re-invented another dozen times in the coming years.

The possibility that someone might steal their work does not deter these programmers from inventing algorithms.

There is no prisoner’s dilemma in software development where everyone waits for the others to invent new things so they can copy them. We have a thriving start-up community bent on inventing new things that almost never patents anything at all. We have an industry that focuses on the quality and nature of the data it collects rather than the ever-changing processes that are applied to that data. The software industry in general does not need patents to keep the innovation ball rolling.

This, in itself, would be no issue — if software companies want to give money to the USPTO for nothing, let them be.

The problem is that software patents are actually hurting innovation. There is a strong tendency for the USPTO to grant patents for algorithms that are not in any way esoteric or unusual, or even new. As a software programmer, I invent new algorithms as part of my daily showering routine ; there is a significant probability that those algorithms are patented either because they are so obvious that a patent-happy company already thought of them, or because they are a special case of one of the surprisingly broad “any computing device, any storage mechanism, any input mechanism” patents being granted recently. The fact that I independently developed that algorithm through logical reasoning, simple modifications of an existing public domain approach, or even genius, does not absolve me from respecting the patent. Sure, I could weasel my way out of the patent by tweaking the algorithm, but doing so is hard for two reasons that are completely unrelated to the underlying technical principles :

  • The only way for me to know what patent I must work around is to look through all existing patents for those that might be applicable to my situation. This means I need to research existing patents as part of my daily shower routine, which is highly inefficient and wastes a lot of water.
  • Even if I was able to identify the applicable patents, I would certainly be able to create algorithms that still did the job without infringement, but I need to hire a lawyer to determine whether there is indeed no infringement.

All of this leads to a massive increase in the cost of developing new software, on the scale of having to check for copyright infringement every time you write an e-mail message. Where software innovation used to be a single engineer working for a few days on a project (which, let’s admit it, is fairly cheap), it now involves much costlier patent lawyers even in the case when no infringement actually happens. Needless to say, most start-ups don’t bother with the lawyers and live at constant risk of discovering that one of the algorithms they created on their own has been patented by someone else.

And all of this happens even when the patent is obviously invalid due to prior art, because it’s usually cheaper to spend a few days working around the patent than to risk going to court over it.

I will not even go into how the monopolies induced by the patent system hurt the users themselves. There have been plenty of discussions on that already.

But there is a flip side to all of this. Patents are not only about inventing new algorithms and processes, they also pay for the cost of validating them. Some algorithms are not solutions to black-and-white, solved-or-not-solved problems where one can prove on the white board that the invention always produces the correct output. Some problems are so complex that any candidate algorithm must be tested against huge amounts of data, and the testing is not cheap. It might be run against data that the inventor has spent a lot of time collecting from the real world, it might be run against data that the inventor had to buy at a steep price, or it might be tested on real-life humans or customers with the risks and costs this involves. And even if the tests themselves are free, there’s the possibility that one needs to try out hundreds of different algorithms or parameters before an acceptable solution is found.

This is almost the same problem as the pharmaceutical industry, where thinking up new molecules is cheap and running the clinical tests is the real cost. The only difference is that algorithm validation is not a mandatory or even obvious process. The various pieces of user interface in Apple, Facebook or Google products might seem utterly obvious when you see them, but each of them passed grueling internal testing processes and survived thrilling tournaments of feature comparisons before ever going live, and these processes and tournaments cost a lot more than the developers thinking about user interfaces during their morning shower.

I suppose the real question that needs to be asked is, why do we have a patent system in the first place? Is it because innovation cannot exist without patents (which is clearly not the case as far as the software industry is concerned) or is it because we somehow feel that pioneers deserve some kind of reward for being the first, even though they were often not the only ones?

Article image © Stuart Heath — Flickr

Pipelines

Published
by
Victor Nicollet
on June 1, 2011
in Strategy
. 0 Comments

You’re a company. Your customers give you money in return for something. They usually start out without any knowledge of your existence and end up giving you money, and the paths they follow are one of the many customer acquisition pipelines you have created (perhaps unintentionally) for your company.

They are called pipelines because they usually convey a continuous flow of customers from point A (never heard of you) to point B (gave you money). Each is comprised of segments:

  1. They just heard about you: maybe you sent them an e-mail, called them on their phone or contacted them through a friend. Or maybe they did a Google search for your product and you were on the results page. Or they saw an ad for your product somewhere. Or your product was recommended by someone they trust. Whatever the reason, they are now aware of your existence. Some of these people will move on to the next step, which is to…
  2. Learn more about you: most of the time, they will visit your web site and sometimes look for references online or in their social circles. Sometimes, they call you, or have you call them, or even ask for a meeting and quick presentation. Either way, some of these contacts will decide that your company or product is interesting enough to…
  3. Try out your product: this could be a free limited-time trial, a demo version, an on-site pilot, a trailer video, a sample tray in a shop, or any other form of discovery that lets them actually experience your product without any serious commitment on their part. You can get away without a demo version if your product is either cheap enough that buying it once does not count as a significant commitment (such as buying a candy) or popular enough that it can convince customers on reputation alone (such as Half-Life 3). Anyway, based on the trial or the reputation, they will decide whether they…
  4. Become customers: this is the interesting part, where you get money in return for whatever you provide.

The number of people at each stage in the pipeline decreases: not all people who hear about you will even visit your website, not all people who visit your website will download the demo, and not all people who download the demo will buy the full version. Since having more people at the bottom of the pipeline is a good idea, a lot of efforts will go into making the pipeline more efficient — losing less people along the way. The customer conversion rate represents the percentage of customers that go from point A to point B, and you usually want the CR to be as high as possible.

In practice, there are two other important things to keep in mind : the customer acquisition cost is how much money you spend on a given customer (on average) to get them through the pipeline. If your pipeline costs you $200,000 in advertisement, phone bills, salesman wages and bonuses, to turn 1,000,000 people into 1,000 customers, then your CAC for that pipeline is $200/customer. The customer lifetime value is how much you can expect to earn from that customer over time, after subtracting the cost of the products you sold. If a customer pays $5 for a book that cost you $2 to manufacture, and never comes back, their CLV is $3.

What matters, then, is not the customer conversion rate, but your net profit per customer : CLV – CAC. A pipeline with a CAC of $200 that leads to a book-buying CLV of $3 is a pipeline that wastes $197 per customer in marketing-and sales-related costs: you spent $200,000 to have 1,000 customers buy $5000 worth of books (of which you only get to keep $3000) for a net loss of $197,000 ! In short, your job is making sure that the CLV – CAC difference is as high as possible in all your pipelines.

The reason why increasing the CR is a good idea is that a higher rate means more people come out of the pipeline, so the total pipeline cost is divided among all of them, and thus the CAC decreases. If I were to double the conversion rate on the above $200,000 pipeline, I would get 2,000 customers and the CAC would decrease to $100. Usually, a higher CR means lower CAC, but this breaks down when increasing the CR costs money: if you paid an additional $300,000 to get the better advertisements and salesmen that allow you to jump to 2,000 customers, then the CAC would actually increase to $250 ! Similarly, lowering the price usually means more people will become customers, which increases the CR and decreases the CAC — but it will also have an impact on the CLV, since you are now earning less money on every customer. If the price drops by $10 and the cost drops by $7, you just lost $3. Per customer.

Optimizing Pipelines Is Hard

The entire issue of sales and marketing can be summed up in a single short sentence:

You have to tweak the customer pipeline, which costs money, and you have no idea whether the conversion rate will improve enough to pay for the changes.

Usually, people have reasons to leave the pipeline other than the price. By finding those reasons and addressing the underlying issues, you increase the conversion rate. So, your course of action is:

  1. Find out why people are leaving the pipelines.
  2. Find out how you could eliminate or mitigate that issue.
  3. Estimate how much it would cost, how the conversion rate would evolve, and the resulting acquisition cost.
  4. Pick the solution that improves the acquisition cost the most, and implement it.
  5. Go to step 1.

Steps 1 and 3 are the difficult ones.

Step 1 is difficult because you need to determine why people who are not your customers don’t buy your product. Do you have an on-site satisfaction poll ? Do you send them a quick e-mail ? Do you have their contact information at all ? Do you even know what your conversion rate is ?

Step 3 is difficult because you actually need to estimate how many people would buy based on that one change. This is even harder, because people can always find new reasons not to buy, so that number will probably be smaller than your estimates from step 1.

These steps usually turn into the easier sequence known as A/B testing:

  1. Guess, or pay an expert to guess, why the people might be leaving the pipelines.
  2. Implement a solution that addresses the issue.
  3. Compare the new (B) and the old (A) conversion rates.
  4. If the solution actually improved profits, keep it !
  5. Go to step 1.

This solution does work, but it has two pretty heavy limitations. The first is that the solution from step 2 needs to be fairly cheap — it would be insane to implement a new major feature only to discover that no one cares about paperclip-shaped assistants. So, if the actual reason people are not buying is that a critical feature is missing, you will not find out through A/B testing.

The second limitation is that A/B testing has high fixed costs, because you need to actually change page layouts and shopping cart workflows for every test. These costs are one-shot, so they will be spread over all the customers coming out of the new pipeline — spending $1000 to get from 10,000 customers to 15,000 customers is a bargain, spending that same $1000 to get from 10 to 15 is not. So, unless your existing pipeline already has a fairly good throughput, A/B testing solutions to significant issues might just be too costly.

Article image © Brian Cantoni — Flickr

Rewrite Your Code

Published
by
Victor Nicollet
on May 24, 2011
in Imperative
. 1 Comment

Writing code relies on four kinds of decisions:

  • What algorithm can implement this feature?
  • How is that algorithm best written in that specific language?
  • What platform quirks and subtle edge cases must be accounted for?
  • How does this code fit in with the rest of the application?

Regardless of team experience or preliminary analysis, some of these decisions will be incorrect. Maybe the algorithm failed to take into account the unusual distribution of real-world data ; maybe there was a better way to write it ; maybe there’s a subtle bug that will not be discovered for weeks ; maybe a possible code reuse has not been identified during the design phase… or maybe the customer requirements that the feature was based on were not actually adapted to the customer needs.

Such bad decisions get in the way of users, but they also hinder developers, who have to regularly work around existing bad decisions, which in turn causes more bad decisions to be made in recurrent “lesser of two evils” situations.

It is a good idea to go back on your bad decisions and make new ones instead. They will not necessarily be good, but at least they will address some of the problems with the old ones.

Don’t try to go back on everything at once. Most of the time, the shortcomings of a decision can be identified in hindsight, change too many things at once and hindsight will be lost. In particular, throwing away non-trivial portions of code (anything beyond a single function) in order to rewrite it from scratch is quite risky, especially since it might also discard good decisions that would be hard to retrieve.

Don’t make your code difficult to change. Going back on your decisions will involve rewriting code. Lots of it. So far, most of the code in the RunOrg project has been rewritten at least three times. Make sure your language, frameworks, libraries and unit tests all work together to make it easy to evolve specific parts of your code to change decisions. The worst situation for a project to be in is code freeze — changing code is forbidden because it’s too risky and it might break something. If you suspect that your project might be heading that way, immediately drop everything you are doing and bring your project back to an acceptable state ; if you are not allowed to do so, make sure you send out a warning to anyone who might need to know.

Don’t make too many decisions. This is usually spelled out as YAGNI : You Ain’t Gonna Need It. If there is currently no need for a given feature, other than the fact that it should remain possible in the future, then don’t implement it. Implementing it will involve making many decisions about how it should happen, and lack of practical application will increase the odds that those decisions are wrong.

Don’t be afraid to go back on huge decisions. Weeks ago, an initial decision we made on the RunOrg project turned out to have huge performance implications. I was faced with two choices : keep that decision, and manually optimize the locations where the performance suffered the most (this involved manually handling caching and batches) ; or go back on that decision, re-architecture the entire database access system and propagate those changes throughout literally half the project, in order to allow automatic caching and batch construction in ways that manual optimization could never allow. The rewrite took me four days, with some aftershocks being felt several days afterwards (strangely enough, changing 20k lines of code resulted in only four fairly obvious bugs).

What does your decision-making process or pipeline look like? What does your decision postmortem and reversal process look like? How often do you go back on your decisions?

Article image © Barb Crawford – Flickr

Work ≠ Progress

Published
by
Victor Nicollet
on January 18, 2011
in Strategy
. 0 Comments

I did a lot of work today. Mostly, I tracked down and eliminated a nasty little problem related to our @runorg.com email addresses and our DNS records.

DNS is the directory system which determines which particular computer handles the requests to a given domain name. So, if you’re looking for holy-grail.runorg.com, a DNS entry mentions that it points to the machine known on the internet as 188.165.231.88, which happens to be our main production server.

The MX records are used when you’re looking for the mailboxes for that domain. This is because usually, you don’t want your web server to handle your e-mail: it’s handled elsewhere, such as another company server, or maybe gmail. So, you can specify a main DNS entry for your domain and then use the MX record to point to another server specifically for e-mail.

Finally, the CNAME records represent the canonical name. We don’t want our main web site to be available both on http://runorg.com and http://www.runorg.com, because it’s confusing and bad for the search engine ranking. So, I pointed a CNAME telling that runorg.com should point at www.runorg.com.

What I did not take into account (or even know) was that CNAME records are meant to be of a higher priority than MX records. So, when someone sent an e-mail to foobar@runorg.com, it would undergo canonicalization and point at foobar@www.runorg.com instead. Since there was no MX record for the latter, the e-mail would then disappear into the void. Our tools and newsletters apparently ignored the CNAME when sending e-mail, so we received those correctly.

So, my entire day was spent hunting down an obscure, unpredictable and not-quite-documented error in my DNS records. It was necessary work and it certainly kept me busy, but it wasn’t progress.

Our team has a looming deadline: the delivery of our first version of the software. It’s when we move from an “implement all the stuff we need before we can deliver” strategy to a “improve or add features to the existing product” strategy (which is an entirely different mechanism). Progress is what brings us closer to that transition — while dealing with the DNS issue was necessary, it did not move me an inch closer to delivering version 1.0.

What is the single largest difference between working as an employee for another firm and working on your own Start-Up? Before I started, I would have guessed it would be the work hours (I now work week-ends quite often), the commute (I work at home because we’re too small to need offices), the freedom (I’m literally by own boss) or the lack of money (no comment). Now it’s pretty obvious that the single greatest difference is that I now emphasize progress more than I emphasize work.

In my previous jobs, there was a fixed set of objectives which had to be accomplished, so I would just come to work every day and chip away at the monolith of work to be done, and since it all had to be done anyway, I could do it in any order I wished. Since I’ve started working on my Start-Up, I find myself increasingly questioning the very objectives I’m trying to accomplish — is this going to let me ship sooner, or not? The freedom of choosing (and discarding) my  objectives myself comes with the responsibility of making the right choices.

That’s a question I never asked myself before.

When you think about it, there are many things that are work but not progress. Some are done because it feels easier to do them sooner rather than later. Others are done because, let’s face it, sometimes you have low morale and a neat exciting feature comes up that you’d rather implement even though it’s purely gratuitous (I added a CSV export feature recently that is not necessary in any way, and I know my definition of exciting is weird but bear with me). Others stem from the necessary shame of delivering a half-baked product, but bear in mind that:

If you are not embarrassed by the first version of your product, you’ve launched too late.
- Reid Hoffman, LinkedIn founder

Delivering a huge product with a small under-funded team is ultimately a find-the-shortest-path endeavour. Choose your next objective based on that.

Diagon Alley – When to Jump on the Bandwagon?

Published
by
Victor Nicollet
on January 10, 2011
in Strategy
. 3 Comments

In J. K. Rowling’s Harry Potter series, Diagon Alley is a fictional place in London filled to the brim with magic-related shops and institutions, hidden away from the eyes of non-magical humans. It makes sense, if you’re a wizard wishing to establish a new shop and seeking as large an audience as possible, to do so in Diagon Alley: not only would you benefit from the existing infrastructure that keeps Muggles away and allows easy access to wizards, but you would also have improved access to the customers of existing shops that happen to be in the area. More wizards walk through the alley in minutes than would walk through any other street in London over the course of an entire week.

In Paris, I enjoy the services of our very own Diagon Alley. It is actually called Rue Monsieur-Le-Prince, and it can be found stretching from the Luxembourg gardens near the Senate and north up to the Place de l’Odéon. Instead of magical shops, it is home to a massive number of Japanese sushi restaurants: Itadaki, Tokiotori, Kiotori, Yokorama, Top Sushi, Sushi Yaki and Sushi Royal among others. The number of such restaurants is surprising: this is a short, narrow one-way street, much smaller than the nearby Boulevard Saint-Michel and Boulevard Saint-Germain, which means that you literally cannot walk ten feet without seeing a sushi restaurant. The local market for sushi food is beyond saturated, and the competition between restaurants is fierce — a quick strategic analysis would determine that a new restaurant would enjoy far less competition if they were to establish themselves anywhere else.

This is not caused by a heavy immigrant population. In fact, the area is known for its high real estate rates and is out of reach of the average immigrant budget.

Nor is this a unique situation: Rue Saint-Anne is a sister street on the other side of the Seine where most of the Donburi and Okonomiyaki traditional Japanese restaurants can be found. All together, clustered on a single street.

This makes no sense. Why is this happening?

Back in 1991, Paul Krugman penned Increasing Returns and Economic Geography: as transportation costs decrease and economies of scale increase, Krugman argues, it becomes more efficient for a given industry to concentrate in a single location, because the transportation costs involved in having to move the products are paid for by the economies of scale involved. For instance, building cell phones in a single city and selling them in an entire country is cheaper than having a cell phone factory in every city.

Sushi restaurants have minor economies of scale as far as production goes: fresh fish is a bit cheaper when the delivery does not involve a one-hour detour (especially since small daily deliveries are involved to keep the fish fresh), and it’s easier to set up a new sushi restaurant in a building previously housed another that went bankrupt, because the fridges and tools and kitchen are already there. But does this explain everything?

Actually, there are economies of scale in marketing here: being an exotic food, a local market alone is not enough to support a sushi restaurant because most people don’t eat there daily. To survive, a restaurant must have a brand strong enough to cover a wider area. Few sushi restaurants have the power to create their own brand, but a dozen of them on a single short street is enough to make Rue Monsieur-Le-Prince the de facto location where sushi and yakitori can be eaten. This, in turn, creates an incentive for more sushi restaurants to appear there: customers are loyal to the street, not the individual restaurants, and a cleaner (by virtue of being newer) restaurant might attract more customers.

Of course, there’s still niche sub-markets within the street:

  • There’s at least one restaurant open for lunch or dinner, including holidays and week-ends.
  • There’s at least one restaurant open on afternoons.
  • The restaurant closest to the large Luxembourg underground station also happens to be the largest, in order to have as many customers as possible with average food quality.
  • There are two restaurants with quiet, clean private rooms for business customers.
  • There’s at least one restaurant with a nice second-floor view on the Boulevard Saint-Michel.
  • There’s at least one tightly packed chinese-friendly restaurant.

In conclusion, while there are advantages to finding your own market and having a monopoly there, there are also advantages to sticking close to existing competitors in the form of economies of scale in production and marketing: if you use mainstream tools, you will find more support for them ; if you provide a well-known kind of service, you will have an easier time convincing your customers that they need it.

The RunOrg Poll

Published
by
Victor Nicollet
on December 20, 2010
in Strategy
. 0 Comments

This week-end, we published on the RunOrg website a poll about the use and misuse of information technologies in associations. Why? Because we’re Start-Up founders, and working week-ends is part of the package. Ha ha, I mean, why this poll? Oh, right. I’ll get to that in a minute, but first, if you’re one of my french readers and happen to be a member of an association, please visit the poll page and respond. It won’t take long, and it might also answer that question.

So, why this poll? Well, there’s a distinct lack of statistical information on the topic — and although our market analysis answers the critical question of whether there’s money to be earned, it’s not nearly as precise or global as our curiosity would expect. There are many problems that information technology can solve in association, and until we take over the world in Q4 2011 we don’t expect RunOrg to solve more than a handful of these by itself, but we would still be happy to know what these other problems really are and how they are solved so far.

Gathering information about unexplored topics is also a great way to build a reputation of expertise and excellence. The results of the poll will be made available freely on the internet, in the same fashion as OkCupid’s How Races and Religions Match in Online Dating and the Mint infographics, which should improve our google ranking bring us more customers help people find the Association IT experts they have been looking for.

The results should be interesting, but the questions themselves are hopefully quite helpful: most of them are pretty obvious to natives of the information age, yet a complete surprise to everyone else. A significant number of associations from our initial sample still rely on a pen-and-paper system for handling everything, with a nice web site designed for them by a tech-savvy member that left two years ago (and that hasn’t been updated ever since). If something as simple as getting the web site right is so hard, what about handling a newsletter or mailing list? Letting members pay their subscription fee online? That our poll asks associations whether they do it hints at the possibility of doing it.

Oh, you can have people pay their subscription online? Asked one early participant (well, poll beta-tester, actually), who has since set up a PayPal subscription process.

If we’re in the business of building wondrous solutions to pervasive problems, I’d rather have everyone know that these problems can be solved. I strongly suspect one of the biggest issues with our product is that our potential clients believe no solution exists — anything we can do to alleviate this issue is welcome, even if it means those potential customers will also become more aware of our competitors’ products in the process.

Really, I’d rather have everyone using our competitors’ products than using pen and paper in the XXIst century.

Amazon-WikiLeaks sets a Scary Precedent

Published
by
Victor Nicollet
on December 2, 2010
in Strategy
. 1 Comment

For those of you living under a rock and not having an internet connection down there, here’s the story so far:

  • WikiLeaks, originally hosted in Sweden, announces that it will publish several hundred thousand U.S. classified documents.
  • A hacker runs a denial of service attack on WikiLeaks, bringing them down.
  • WikiLeaks uploads some of their data to Amazon’s S3 file hosting service, and goes live
  • Amazon pulls the plug on the WikiLeaks hosting within 48 hours.

I will not under any circumstances condemn or condone what either WikiLeaks or Amazon did there. That topic is too complex for me (and, I suspect, most people) to form an adequately justified opinion, and my biased unjustified opinions are best kept off the Internet.

On the other hand, what Amazon did was terrifying. After toiling for years to convince the general business public that moving to the Cloud does not imply accidental data loss or vicious hackers accessing your secrets, Amazon have reminded us of a basic, uncomfortable truth: they who handle your data can kill you on a whim.

«But WikiLeaks is not dead!»

I know. Keep in mind that WikiLeaks team has backup copies with strong encryption stored by a multitude of anonymous individuals, access to international hosting in a variety of safe havens, a dedicated team of sysadmins on call to move around the site and the data whenever something dies, and a willingness to fight for the availability of that information even if it entails going to jail. The reliability of their data storage exceeds that of almost any other entity on the planet, including Amazon S3. To them, having their hosting shut down is a minor inconvenience. To a normal business with their data to the Cloud, and all the bills, orders, paychecks, contracts and documents for the last year are lost: it’s an unmistakable death sentence.

How can Amazon S3 do this? Here’s the relevant part of the Amazon Web Services customer agreement:

3.4. Termination or Suspension by Us for Cause. We may suspend your right and license to use any individual Service or any set of Services, or terminate this Agreement in its entirety (and, accordingly, your right to use all Services), for cause effective as set forth below:

3.4.1. Immediately upon our notice to you in accordance with the notice provisions set forth in Section 15 below if:

[...]

(vii) we receive notice or we otherwise determine, in our sole discretion, that you may be using AWS Services for any illegal purpose or in a way that violates the law or violates, infringes, or misappropriates the rights of any third party;

This grants Amazon the right to terminate your service by snapping their fingers (and sending you an email) if there’s any hint of you doing something that might be construed as illegal.

«You’re another guy who stumbled upon a piece of legalese in a customer agreement, misunderstood it, and tells everyone how evil that corporation actually is…»

No, I’m not. I knew this termination clause had to be in there before I even looked, because it’s a fairly standard one and even my own business has it. Amazon needs this part to be able to eliminate child pornography or copyrighted books/songs/movies stored on its servers without waiting for a judge to determine that the content is actually illegal. There’s nothing evil about having that clause, and the reason we accept this situation is that we expect Amazon (and any other service) to use this power responsibly: as long as you don’t store any illegal files, you need not fear anything.

Keep in mind that while obtaining those leaked documents was illegal, distributing them has not yet been ruled illegal. It might happen in the near future on the grounds that it endangers individuals and/or governments, or it might end up under the protection of the First Amendment, and there seem to be fairly intelligent and reasonable people arguing for both sides.

You just moved your data/computations to Amazon to eliminate any data loss or denial of service risks. But now, there’s the risk of Amazon shutting down your account — what are you doing to make sure that isn’t going to happen? How do you intend to get back up once it happens? Is it really worth it?

1170 feed subscribers
(readers who polled a feed this week)