Archive for the 'Strategy' Category

freedom.txt

Published
by
Victor Nicollet
on January 23, 2012
in Strategy
. 0 Comments

Francis suggested the freedom.txt idea in early January. It’s catching on. I think this is a good idea, although I do not agree with the wording of the message, so here’s mine.

You might not understand what I am rambling about in the two sentences above. What is going on?

Until recently, humans were fairly similar to each other in terms of capabilities. If an individual decided to annoy, harass or harm others, their impact would be limited to what they could do on their own before being stopped, or they would have to convince enough people to help them. When you were a large organized group of people, you only had to care about other large organized groups of people.

Even with the advent of modern technology up to the 1980s, when two people in a stealth bomber could mash tens of thousands to a pulp by pressing a button, this was still the consequence of an industrial infrastructure allowed by a large organized group that willingly granted those two people such power.

Guns are a special case. An individual with a gun can do more damage than average, faster and without retaliation. What happened next is hardly surprising: some people decided to fight fire with fire and buy their own guns as a deterrent, while others decided that gun ownership — or rather, the increase in destructive power provided by guns — should be heavily regulated.

And then, computing and the internet happened. Owning an internet-connected general-purpose device is quite affordable these days.

And owning an internet-connected computer increases the capabilities of individuals by several orders of magnitude, as far as processing data and communicating with others is concerned. While computers are not as lethal as guns (tech support calls excluded), the increase in lethality provided by guns is much smaller than the increase in processing power and communication reach provided by computers. This is literally the first time that we, as a species, have to deal with some individuals having enough power to harm, disrupt or topple large organized groups.

A handful of people can harness the power of computing to send billions of spam messages, bring down entire web sites or networks or nuclear plants, make elite KGB spies green with envy, collect personal information about thousands of people, tell millions of people about a new law that mainstream media are silent about, or illegally distribute content without compensating its creators.

Is it any surprise that corporations, organizations and countries are fighting to regulate such incredible power?

You may not run software on iWhatever devices without consent from Apple. In France, you are legally responsible for when third parties commit crimes using your IP address. Various laws around the world including SOPA, PIPA and ACTA aim to provide counter-measures to illegal distribution of content. Germany and the UK are getting anal-retentive about what cookies you are allowed to send to your users.

And yet, there are immense benefits still to be reaped from a free, open, uncensored internet, and I am certain they far outweigh most of the costs involved. To willingly throw away those benefits in order to maintain existing business models and political habits strikes me as a very bad idea indeed, and one we should fight against.

Another alarming development is that the general public, lawmakers included, are woefully incompetent when it comes to computers and the internet. They do not understand why it works, and so they do not understand why actions they take might prevent it from working or what negative consequences. Laws are drafted and voted on without asking any experts for input, even when experts are quite outspoken against them.

And we, the experts, are the cause. We are dealing with people who thrive on communicating with the public — we are fairly good when it comes to communication, but only with each other. Is it any wonder that no one listens to us? We are so familiar with the details, nooks and crannies of our high-tech world that we fail to explain, in simple terms, why non-experts should care about these issues.

Why did it take something as critical as SOPA and PIPA to get us moving? Shouldn’t we be the ones leading the conversation on computers and the internet, instead of mumbling in our collective niche beards when clueless members of our parliaments speak of «series of tubes»? Could it be that we are so used to wielding awesome individual powers of communication, that we have forgotten how to team up to make our voices heard?

Consensus and Compromise

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

Working on a start-up involves many decisions — how features should work, how pages should look like, how advertising should be written… and making decisions is a difficult process when working as a team. Even in the tightest-knit team of two, disagreements happen.

Sometimes, on the less important decisions, you might get out of it by default — A disagrees with B, but doesn’t care enough about the topic to actually do something about it, so B proceeds anyway.

Sometimes, decisions will be dictated by competence. If A disagrees with a proposed solution because of objective technical or legal implications, well, that’s it.

Quite often, though, there is no such solution. This is where one must be aware of the dangerous tendency of consensus-based teams to devolve into compromise-based discussions.

Consensus-based discussions feel like this :

A: I’m going to frobnicate the thingamajig.
B: If you frobnicate the foobar instead, you would get a 10% increase in floogum output.
A: You’re right. Let’s frobnicate the foobar, then.

That is, initially differing opinions evolve through an argumentation process, so that everyone agrees that the final outcome is the best one.

Compromise-based discussions feel like this :

A: I’m going to frobnicate the thingamajig.
B: I would rather that we frobnicate the bazquux instead. Might get better results.
A: Actually, I have a hunch that the thingamajig is the better option.
B: Tell you what, let’s frobnicate 50% of the thingamajig and 50% of the bazquux. This way we have everything covered.
A: All right.

Here, initially differing opinions are settled through a negotiation process, so that everyone’s input is respected, but no one agrees the final outcome is really the best.

Compromise is a bad idea for several reasons.

  • Quite often, going 100% with any reasonable solution is better than investing only 50% into two different solutions. In more general terms, lack of commitment to a single strategy or objective is a dangerous thing to do, and often less effective than commiting to any strategy or objective one might come up with.
  • Compromise is not agreement, it’s negotiation : you give something and get something else in return until everyone agrees that it’s an even trade. People who are good negotiators tend to dictate their terms in such circumstances, and others might feel helpless and useless after a few unbalanced trades. It also leads to « I agreed with your idea yesterday so agree with mine today » or « You’ve already changed my idea enough, stop asking me to change it again, » both of which are content-free sentences that aim to make a decision based on interpersonal history instead of objective analysis.
  • The inability to come to a logical conclusion sometimes happens because there is not enough data available to decide. The first priority in such circumstances should be to actually search for the data (possibly accepting one of the proposed solutions as temporary until the data is collected), not settling for an arbitrary compromise.
  • Building consensus is hard when people have trouble putting their insight into words, no matter how convincing or true that insight might be. I’m objectively right, but I cannot seem to explain to you the reason for it. This can mean going for a compromise today instead of a consensus tomorrow — hasty decisions are seldom good. Always make sure everyone has had enough time to think the decision through, even if it means adjourning it until later.

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

Toppling the Stacks

Published
by
Victor Nicollet
on October 3, 2011
in Strategy
. 2 Comments

Everyone agrees that CSS is an overly verbose stream of boiling pain, but not everyone agrees on how it should be solved. Sass is one such solution — a language extension that supports standard CSS code natively, but provides several tricks that make the maintenance of stylesheets easier, not least of which being the ability to nest selectors:

.profile {
  color: black;
  .name { font-weight: bold; }
}

A compiler turns the above into standard CSS:

.profile { color: black; }
.profile .name { font-weight: bold; }

Typical usage of Sass is to write the former by hand, run the compiler, and move the resulting CSS file to wherever the browser can see it.

I successfully set up Sass on my development machine and uploaded the generated CSS to source control. This worked correctly for a few weeks.

Then came the time when I had to set up Sass on the deployment server, because not everyone on the team had the time or the operating system to set up Sass on their computer. It burst into flames almost immediately with an arcane stack trace:

.../rubygems/defaults.rb:40:in `exist?': Insecure operation - exist? (SecurityError)
    from .../rubygems/defaults.rb:40:in `default_path'
    from .../rubygems.rb:752:in `path'
    from .../rubygems/source_index.rb:59:in `installed_spec_directories'
    from .../rubygems.rb:1051:in `source_index'
    from .../rubygems.rb:243:in `activate_dep'
    from .../rubygems.rb:236:in `activate'
    from .../rubygems.rb:1307:in `gem'
    from /usr/local/bin/sass:18

I posted an issue to the GitHub issues tracker for Sass. The answer was underwhelming :

This looks like a Rubygems issue, not a Sass issue.

And the issue was closed.

Let me set things straight here: when a Sass user cannot use Sass, it is a Sass issue. Yes, the underlying technical cause of the issue is probably somewhere inside that «Rubygems» thing I sincerely know nothing about, or maybe it lies in the Debian package for it, or maybe I’m just setting up my environment variables badly and just need a clean diagnosis to fix that up, but Sass is not working. Even if you have absolutely no personal responsibility for the issue, pointers such as «ask about this on channel X or mailing list Y» are most welcome.

Now, I don’t expect nex3 to provide me with free support. This is an open source project, and there’s nothing unusual or wrong with having no technical support on open source projects. In fact, given the size of the technology stack sitting under Sass, this was probably the best thing to do in terms of project strategy — only cater to users who can get the underlying stack working on their own.

This is not a matter of fairness or ethics, but one of incentives. I have no need to keep debugging Sass — the path of least resistance is precisely to replace Sass with an equivalent working tool. Rewriting a handful of Sass rules over to Less CSS is easier for me than tracking down bugs in the Debian packaging of «Rubygems». And the deployment server runs Less without a hitch.

I shudder to think what would have happened had I locked myself into more esoteric Sass language features.

Article image © yimmy149 — Flickr

The Plans & Pricing Page

Published
by
Victor Nicollet
on July 25, 2011
in Strategy
. 1 Comment

While creating my own Plans & Pricing page, I collected screenshots of those same pages from a variety of companies. This helps illustrate both what everyone is doing, and how some of them are innovating on the matter.

backupify.com – backups for cloud data

basecamphq.com – online project management

bitbucket.org – online code hosting

ginzametrics.com – SEO analytics

github.com – online code hosting

huddle.com – online project management

raventools.com – SEO analytics

rhapsody.com – cloud music service

seomoz.org – SEO analytics

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

I’m Going to Miss the Internet

Published
by
Victor Nicollet
on May 19, 2011
in Strategy
. 3 Comments

My first dealings with the internet went through a 56k modem. I had to find and save pages to the computer to browse them offline in order to avoid the large phone bills that came after you stayed online for too long. These days, I have five computers plugged into a single fat pipe at all times, with more bandwidth than I could ever use, at one hundredth of the former cost. But still, as the internet and the computing world improved and matured, some key aspects were lost.

Browsing the internet used to be an anonymous activity. As you came online, you were awarded an IP address, which acted as your avatar in your dealings with other computers on the network. There was no way for anyone on the internet to reliably trace any kind of online activity back to your real-life existence, because there was no link between IP addresses and human beings. Even if someone did find out that you owned a given IP address, you could still argue that it had belonged to someone else when the activity took place. Sure, a handful of countries that were known for their human rights track record could play Big Brother with their citizens, but I lived in a first world country that would certainly respect my right to privacy. I was wrong. Browsing the internet in France is no longer anonymous, as internet service providers are required by law to log the owners of every single IP address they allocated. There is now a link between your IP address and your name and home address, and government agencies may follow that link to hunt you down.

I used to believe that the Internet was immune to such tampering because it was decentralized, that the RIAA and MPAA were fighting a losing uphill battle, that any attempt to restrict online freedom would be voided by technical counter-measures and workarounds. This belief was epitomized by John Gilmore in his 1993 quote:

The Net interprets censorship as damage and routes around it

This warm feeling of eternal resilience relied on a single assumption : almost every single data transfer technology can be abused to transfer illegal data (the latest Lady Gaga single, child pornography, mentions of Tian’anmen Square), and the government cannot afford to outlaw all data transfer technologies. I call this the Collateral Damage Assumption — any effective solution would involve too much collateral damage to be implemented by lawmakers. But this assumption, as self-evident as it may seem in a first world country, is incorrect.

Subtle side-effects

One reason why this assumption breaks down is that lawmakers only care about flashy, obvious side-effects. They honestly believe they can get away with subtle side-effects, so they will settle on solutions that hide away the collateral damage so that taxpayers will not notice it until it is too late. I have an actual example here, so bear with me.

A few years back, copyright owners spied on peer-to-peer networks to identify the IP addresses of illegal downloaders, traced those back to the actual names and home addresses of real-life people, sued them for infringement, and failed because there was no proof that those people were actually guilty of downloading copyrighted works, as opposed to merely being the unlucky owners of a hijacked WiFi network — it takes a few minutes and a few dollars to hack into a secured WiFi network, not to mention all those open WiFi hotspots in various restaurants and institutions.

Then, the law that became known as HADOPI was introduced. Among other things, the bill made it a misdemeanor to connect to the Internet a device that is insufficiently protected against malicious users. If a copyrighted work was downloaded from your IP address without your consent, then you failed to protect your internet connection against that malicious user and you would be sentenced for the misdemeanor. Can you swear that your home network is secure? Do you regularly change the WiFi key, keep your router firmware and operating systems up to date, and monitor your traffic for any suspicious activity? Me neither, and I suspect the average Internet connection owner does not even understand what changing a WiFi key involves.

The media and several activist groups made a fuss about the fact that the sentence carries the possibility of being barred from owning an internet connection for an entire year. That’s annoying and extreme, but certainly not the main issue.

Few recognized this law for what it was: reducing the number of false negatives (letting pirates off the hook) at the cost of having more false positives (punishing helpless, innocent people). But those false positives are a subtle side-effect: the only people who notice are those directly affected by it, and those with the technical skills to understand that securing an internet connection is hard. Outside of well-informed technical circles, the general opinion on the HADOPI remains that you will only be punished if you download copyrighted works.

And there were even subtler effects. One of them was that many pirates, aware that they were at risk of being discovered, started using encrypted file sharing protocols in order to evade detection. This significantly increased the amount of encrypted data over the network, because downloading the latest episode of The Big Bang Theory uses more bandwidth than all your HTTPS browsing and SSH terminals combined. Needless to say, the NSA was less than happy about having a lot more data to sift through to when looking for terrorist threats.

While on the topic of subtle collateral damage, there is yet another example, this time in an otherwise fairly decree by our government. Around these parts, laws provide a general framework, and decrees are then used to fill in the details such as what forms should be filled, how much money must be paid, or what data is covered by “should keep the relevant information for at least one year”. In this case, the decree asked for user passwords to be kept around for at least one year, going against the fundamental principle of password security which is to never store user passwords, ever. I’m fairly certain that the people who added “and passwords” to that decree had absolutely no idea that this was an insanely bad idea, and I suspect that it would take quite some time to explain exactly why it’s such a bad idea.

General Misunderstanding

In the end, we live in a world where only a small technical elite can hope to understand the consequences of such decisions — and that is when we do agree with each other. Decisions by the unsuspecting lawmakers, unopposed by the uninformed general population, can ultimately hurt the Internet in subtle but permanent ways.

This week, the Queensland police likened receiving photos to taking stolen television sets. This is a pretty good analogy, except for the fact that 1° you cannot make a copy of a stolen television by clicking a button and 2° you do not receive thousands of television sets (stolen or otherwise) on a daily basis while browsing the web.

The easiest way to explain computing concepts to normal people is to use analogies, and all analogies are inherently flawed. Hilarity ensues when the analogy is taken to its logical but incorrect conclusion.

To make sane decisions, instate sane laws and pass sane judgements on the computing world, working by analogy is the last thing you want to do. Copyright infringement is not theft. Privacy invasion is not theft. The only acceptable way of dealing with the complex technical concepts around us is to determine their consequences in the real world, and decide based on those consequences.

What are the real-world consequences of a journalist receiving unauthorized Facebook pictures when writing an article about the security issues that allowed the pictures to be obtained in the first place? Are any of these consequences worth arresting the journalist and confiscating his property?

Being Left Behind

There’s another reason why the Collateral Damage Assumption is incorrect. We say to the computer manufacturers “let us install any software we want on our computers, or you will kill the economy” and thus we retain the right to install any software. Can you imagine the next version of Windows refusing to install any kind of peer-to-peer software? That would require some heavy restrictions on installing new software, so no one would buy it.

There was no collateral damage to Apple deciding that all applications on the iPhone must be accepted by the App Store first. They defined a new market and set their own rules, and most people accepted this situation without flinching.

We praised the Internet, and the computing world, for their versatility, for their ability to evolve around any obstacles in their path. But we assumed that this meant those features we held so dear would remain forever. This is completely wrong : the world will move away from any features that do not fit in anymore. I assumed that I would forever be able to participate anonymously on various online communities, but they are starting to use Facebook Comments because there is now a critical mass of people who 1° use Facebook and 2° don’t care about writing things in their own name on the Internet. The “mainstream Internet” has already given up on many earlier features I took for granted :

  • Browsing without cookies or javascript. Now, sites require these even if you do not have an account.
  • Interacting anonymously or with pseudonyms. Now, you need to use facebook.
  • Dealing with many small tools and communities. Now, there are a handful of huge “cloud” conglomerates and communities.
  • Content placed online by competent experts. These days, anyone can create a blog to share they’re [sic] mistakes with everyone else.

As with anything that evolves, nothing is forever, not even those things that we though the Internet could never exist without.

The Internet isn’t dying. It’s becoming something else that I’m not entirely happy with.

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.

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