Closer To The Ideal

Here is a screen shot, note the yellow box that advertises their new book:

I pay $30 a month for Basecamp. I do not want ads on Basecamp. Not even ads from 37 Signals.

Dan Bezdek posted on LinkedIn, suggesting that it was impossible to launch an online business nowadays due to the hyper-competition on the web. He wrote:

I still think there is a huge difference between an online business and a traditional business. We have this grocery store in the neighborhood which is right next to Safeway. Now, you’d imagine there is no hope for this store; however, not only it is surviving, but in fact has so many customers.

He also wrote:

The main problem is that the culture of internet is free service, and this problem will remain with Internet forever. You might spend a couple of years in development, and provide a great service; but you can’t charge users even a $1 except in very few niche sections.

I wrote a response, but LinkedIn limited me to 4,000 characters, so I was not able to post my whole response. I post it here, instead.

- – - – - – - – - – - – - – -

Dan Bezdek, I’m afraid I’m unable to understand your reasoning. I’m going to try to paraphrase what I think you are saying.

You write “It is so easy for anyone in the world to compete with you even in places that $100 is a week pay.”

I think you are trying to say that because computer programmers can be hired cheaply, it is more difficult for you to build a business? But the opposite is true: cheap computer programmers make it easier to launch a new business. I can not think of a single case in economic history where the falling price of a supply factor made it more difficult to launch a new business. A few examples:

1.) During the late 1600s, in Europe, the dramatic fall in the price of paper allowed for the creation of the first modern newspapers. The Spectator launched on March 4, 1712.

2.) During the mid 1700s, in Europe, the dramatic fall in the price of coffee beans allowed for the first coffee houses to open. Paris had hundreds of small coffee stands at the outbreak of the Revolution.

3.) During the late the 1800s, in America, the dramatic fall in the price of communications (the telegraph and the telephone) allowed for the organization of businesses over a distance, and at a scale, never before seen.

4.) During the late 1900s, all over the world, the dramatic fall in the price of computing power brought several new technologies into the mass market, including cell phones, personal computers, and personal (non-business) software.

As a general rule, the cheaper supplies get, the easier it is to start a business.

You also wrote this:

“In any case, the point of all this is to say that developing even a barely successful online business is probably 10 times more difficult than setting up a grocery shop.”

You didn’t mention which country you are in. If you are in the United States, then your statement is incorrect. The retail sector in the US is overbuilt and is expected to consolidate over the next 10 years. Many grocery chains are expected to go bankrupt. Meanwhile, the Commerce Department projects that the software industry will continue to grow, and much of that growth will be happening on the web.

If you do not live in the US, then I’d have to know what country you are in, to know if there is any truth to what you are saying. Some countries, such as France and Italy, offer strong legal protections to small firms. In those countries, small groceries have some hope of surviving, but that is because of government protection, not economic fundamentals.

I think the concept that you are trying to get at is what economists would call “barriers to entry”. That is, what barriers keep competitors from entering your market and competing with you? And I think what you are thinking is that a local grocery store, because it is grounded in a specific geographical space, has some immunity from competition, whereas a web site has to compete with every other web site on the web.

Again, if you are speaking about the US, you are plainly wrong. The history of post-war economic development in the US is the history of retail consolidation. Mom-n-Pop stores have been relentlessly replaced by big chains such as Wal-Mart. Massive numbers of bankruptcies have happened in every state. The small-scale grocery was once common, and now is nearly extinct. They’ve been hunted to extinction through the relentless competitive pressures of market consolidation.

Consider the graph that the US government has posted here:

In the late 1990s, a number of leading grocery retailers went on a buying spree. Between 1997 and 2000, more than 4,100 stores were acquired, amounting to almost a fifth of all U.S. supermarkets. Mergers and acquisitions by large grocery retailers, including Kroger, Albertson’s, Ahold USA, and Safeway, produced a significant increase in the share of grocery store sales by the largest firms. By 2005, the 20 largest retailers accounted for 61.6 percent of total U.S. grocery store sales, up from 40.6 percent in 1995.

If you look at the facts, you’ll admit that small-scale groceries have mostly been wiped out. And this happened during some of the same decades that saw the explosive growth of the US software market.

Clearly, it is possible to make a lot of money on the web. 37 Signals makes millions of dollars in sales, and Amazon makes billions of dollars in sales. AOL is making a shockingly large gamble on weblogs.

You include this surprising comparison:

Now, compare this store to many 2-3 men operations online trying to make it online offerring some service; there are thousands of such operations which wish they were making as much as that grocery store.

I assume you meant “people” where you wrote “men”. A 3 person web start-up will cost less than running a grocery store. Even a small grocery store is going to have more than $50,000 worth of inventory in it, then it will have labor costs, rent or real estate taxes plus land cost, licenses for health, fire, safety, etc. If you are going to compare businesses that have different capital requirements, then you might as well write “I tried to run a lemonade stand, but it never made as much money as Toyota.” The comparison is absurd.

Of course, as segments of the web mature, the capital requirements for starting a web site go up for that particular segment. Once upon a time, a long time ago, you could start a successful weblog for free. Nowadays, if you are starting a weblog which you hope will develop a mass audience, then you should probably have $100,000 for marketing and writers. Likewise, if for some crazy reason you decide to launch a competitor to YouTube, you should start with $100 million in the bank. In the future, you may need millions of dollars to get into any established segment. But some segments will remain open to the sudden hit that comes form nowhere. Weblogs, for instance, began to consolidate some time ago, yet new weblogs still occasionally burst forth and become large-scale hits. And one of the great things about the web (so far) has been the speed with which new segments emerge.

I’ve already written extensively about the costs of building a web site. And I’ve helped launched a number of successful sites that cost less than $100,000 to get going. And I continue to work with start-ups that have budgets under $100,000, and I’ve great faith that a number of these will become successful.

If you are thinking of starting a new business, you’d be wise to start it online.

One of the tough calls to make, when managing a project, is figuring out how much time should be devoted to talking things over. If you are the manager, there are two mistakes that you might make:

1.) You cut off conversation too soon, before the designer has had a chance to defend their idea, or before the client has had a chance to fully articulate their dissatisfaction, or before your programmer can explain why one option would take more time, and therefore more money. You force a decision to be made before all the facts are in. Possibly you kill the conversation just as people are warming up to what would be a brilliantly creative set of insights, if only you allowed more time.

2.) You allow the conversation to go on too long. After awhile, people begin to repeat the same points they made 4 hours before, or perhaps the day before. Your team begins to fear these conversations, which seem to be endless swamps of unproductive debate. The team craves action, decisions, movement, they want to finally be building something, but instead you keep pushing for more information, another round of opinion gathering.

It is difficult to find the right balance. I suspect we all have our preferences about what we consider the right level of conversation versus action.

Over at 37 Signals they’ve posted an extended chat that Jason Fried and Ryan Singer had about adding a new feature to Basecamp. It is useful to see how such a well known and successful team works through their design issues.

(14:42:41) Jason Fried: What are some of the pushback points we’re anticipating?
(14:43:02) Ryan Singer: “i use milestone attachments for [some crazy custom reason] and this doesn’t apply to me”
(14:43:30) Ryan Singer: possibly: “i want dates on my to-do items, not the lists themselves”
(14:44:12) Ryan Singer: i don’t think the first point is a problem
(14:44:18) Ryan Singer: there are always people who bend the interpretation
(14:44:51) Jason Fried: What if the date thing said “On or before March 14”
(14:44:59) Jason Fried: I think the ridigness of it may be a problem.
(14:45:03) Jason Fried: And this could soften that a bit
(14:45:05) Ryan Singer: a bit long, but i like that idea
(14:45:52) Ryan Singer: hm kinda long
(14:46:08) Ryan Singer: becomes harder to interpret too

I know that in such conversations I tend to defer to the designer, and I tend to want to reach a conclusion quickly. Probably because I’ve been in so many, many meetings where someone else forced the conversation to go on for many more hours than was needed, I tend to play the role of the person who is willing to reach a quick agreement. Ryan Singer reminds me of myself, in this portion of the chat, where he seems willing to go along with the “Due by” language, even though he initially disliked it. He seems eager to reach a final agreement.

(14:46:35) Jason Fried: After seeing this the issue I have is the rigidity of it.
(14:46:42) Jason Fried: This list IS DUE on this date
(14:46:45) Jason Fried: Well, not really
(14:46:57) Jason Fried: It’s part of a milestone that is due on this date.
(14:47:07) Jason Fried: So I’d like to see if we can figure out how to present that reality a bit better
(14:47:15) Ryan Singer: good point
(14:47:18) Ryan Singer: ok
(14:47:41) Jason Fried: how about
(14:47:47) Jason Fried: “Due by 14 February”
(14:47:49) Ryan Singer: “Milestone: 14 February”
(14:48:03) Ryan Singer: nice that Due by is shorter
(14:48:05) Jason Fried: Milestone may work. Ties it into the feature.
(14:48:07) Ryan Singer: shorter is better for this flag
(14:48:12) Ryan Singer: even “Milestone: 10 Feburary” is quite long
(14:48:13) Jason Fried: Due by is less rigid than “Due on”
(14:48:15) Ryan Singer: doesn’t hold together as well
(14:48:16) Ryan Singer: yeah
(14:48:37) Ryan Singer: Due by looks pretty good. screenshot coming

But Jason Fried won’t be rushed into a decision. Instead, he keeps the conversation going, even though Ryan Singer was willing to go along with “Due on”.

(14:55:14) Jason Fried: Due is good, but it’s an opinion 5 years after the fact.
(14:55:20) Jason Fried: That’s why I’m pushing back a bit.
(14:55:30) Jason Fried: We’re not introducing attachments today
(14:55:37) Jason Fried: If we were I’d feel better about it.
(14:56:15) Ryan Singer: i think if we don’t go with “Due..”
(14:56:26) Ryan Singer: it would be better to explore moving the link below the title into the list description area
(14:56:30) Ryan Singer: and actually naming the milestone or something
(14:56:41) Jason Fried: right like…
(14:56:54) Ryan Singer: like “For Ship v1 of the Home Page, 14 Feburary”
(14:56:57) Jason Fried: “This to-do list is attached to a “milestone name” which is due on 14 Feb”
(14:57:23) Jason Fried: I feel like we don’t lose anything with that direction.
(14:57:27) Jason Fried: And we gain clarity

If you read the whole transcript, you can tell these two are getting warmed up as the conversation continues – they are thinking hard about this problem, and they are getting deeper and deeper into the nuances. I relate to this chat quite a bit, as it reminds me of so many of the more productive meetings I’ve been in.

Finally, an hour goes by, and Jason Fried keeps pushing them until they arrive at what they both agree is the perfect answer:

(15:20:08) Jason Fried: In the app we say “Attach to…” so I wonder if we should repeat that here.
(15:20:18) Ryan Singer: i would rather change the language in the other places
(15:20:23) Ryan Singer: “Attached to” looks weird here
(15:20:28) Ryan Singer: and it doesn’t fit with the normal expectations of what an “attachment” is
(15:20:36) Jason Fried: K. We don’t want to change the language elsewhere so we’ll consider that one a no go.
(15:20:39) Jason Fried: Umm…
(15:20:46) Jason Fried: “Related to” works for me.
(15:20:47) Jason Fried: Cause it is.
(15:20:51) Ryan Singer: actually the edit dialog says this:
(15:20:55) Ryan Singer: “Does this list relate to a milestone?”
(15:20:58) Jason Fried: Perfect
(15:20:59) Jason Fried: Done
(15:21:02) Ryan Singer: done

Jamis at 37 Signals has up a strange post in which he is critical of modules. I say “strange” because his tone is defensive and he interrupts his post to repeatedly to insist that modules are really great:

The code remains really clean, overall, because we’ve continued to follow the pattern of moving related methods into modules, and just including those modules in the base model.

Got that? Refactoring code out of your main classes and into modules is  a great way to keep your code clean. He emphasizes:

Don’t misunderstand me, though. Modules are awesome. We use them a bunch, and love them.

and then:

Modules are very handy, and as I said before, we still use them extensively.

He seems worried that someone is going to criticize him because of his criticism of modules. Yet his criticism is almost the same as Michele Simionato wrote in last month’s explicitly anti-module post.

Jamis writes:

However, there are two issues with this approach. First, when a class includes lots of modules (as some of ours do), it becomes hard to keep track of where different methods are defined, and even which methods are defined. This can lead to confusion when trying to find the definition of a method, and (worst case) can allow two or more methods with the same name, which is bad. There is no warning if you have methods with the same name in multiple modules, so it isn’t hard to wind up with bugs where you’ve clobbered a method with another. You wind up double-namespacing your methods (e.g., method names in the Avatar module being prefixed with avatar_), to avoid collisions.

…There are more issues with the module approach. What if you have different kinds of avatars (e.g., person versus group, or company)? You can’t subclass modules in Ruby, so you wind up finding other ways to solve it (like including modules in modules, etc.). Also, you can’t reference the avatar as a separate entity; instead, controllers that deal with avatars need to deal with the entity to which the avatar is attached.

And what solution does he offer for these problems? I was thinking he was going to say something really original, because it sounded like he was really wedded to the idea of using modules. But in the end, his solution is to simply not use modules:

Can the avatar code be split out further, somehow? Yes, it can. We’ll do this by making avatars a model of their own and using aggregation (rather than module inclusion, or inheritance) to pull it into Person.

So the solution is simple: don’t use modules, use independent classes and then build your objects through composition. This is probably very good advice, though I was a little surprised by his conclusions, given that he started off sounding like a big fan of modules.

This is impressive. With one small change and 37 Signals reduces credit card chargebacks by 30%:

We’ve never had a lot of chargebacks (a chargeback is when a customer calls their credit card company to dispute a charge they don’t recognize), but last year we made a simple change that reduced our chargebacks by 30% as a percentage of sales.

…One of the issues we have at 37signals is that many people know our product names better than they know 37signals. They sign up for Basecamp or Highrise without knowing that there’s a company called 37signals behind the product.So sometimes people see a charge on their card from 37signals but they don’t know what it’s for. And even if they did remember 37signals, they still may not recognize the charge.

…So I decided to register 37signals-charge.com, redirect it to 37signals.com/charge, write up a page explaining why there’s a charge on your card, and put that URL on people’s charge slips instead of “37signals, LLC” or “Basecamp” or “Highrise” etc.

Now when someone buys something from us, this line item shows up on their credit card statement:

37signals-charge.com 800.xxx.xxxx IL

Visiting that URL takes you to this page where we explain the charge, the products, some suggestions if you don’t recognize the products, and a link to our billing support form someone needs additional help.

These are articles that I’ve often spoken of, and often copied the URLs to emails that I’ve sent to others, so I shall record them here, so in the future I shall only need to point people here.

The illusion of agreement:

“We should build a house!”

“Yes! A house!”

But what kind of house do they mean?

The interface as a spec: including stories inline:

Sometimes designing the static states takes more time, and doesn’t quite represent reality, as well as a brief note about how the functionality works. The key is to make this note in context — right next to the interface element its describing. The combination of real visuals and a brief contextual note shrink the chances of misunderstanding to near zero.

Designing an interface: from sketch to screen

The screen mostly followed the sketch, except for the controls in the upper right and the description field. That’s fine, because at step two those details Didn’t Matter. Coding the real thing, I found room for all three of those pieces in the top-right, and that worked better.

Thinking and sketching took me 10 minutes. Creating the real screen and updating the code can take two or three hours. That lopsided pattern, with short make-believe-time on the left and long build-time on the right, is always a good sign that you’re making progress. Ideas and paper are necessary, but they’re destined for the trash bin. So burn through them and focus on the good stuff.