It’s easy to take for granted just how good we have it as software makers selling on the internet. This is truly a unique period in human history with unprecedented commercial freedom. It bears celebration and recognition.

Let me count the ways I love thee, unregulated internet:

• Access to world markets: Out of the 195 countries recognized by the US state department, we have customers in 191. There are no import tariffs to pay. No customs to clear. No multitude of electrical standards to comply with. Heck, we don’t even need to translate our products.
• Direct sale to customers: There are no distributors and no retailers with their hand out to take a cut. And we, the makers, get to talk directly to our customers—not someone else with a million other products to sell and none of our expertise.
• Free tools and education: All the software we needed to build our business with was not only freely available off the internet, it came with a wealth of free education that would shame any university. Programming languages, database systems, web servers, load balancers, operating systems. It was all there for the taking.
• No capital requirements: We didn’t need offices or fax machines or secretaries to get going. We could rent all our computing needs for next to nothing until customers with cash in hand started using our services and taxing our servers. This meant basically “no money down!” and no need to go hat in hand begging banks or venture capitalists for money.
• Self promotion can build a brand: We didn’t have to either convince journalists to write about us or buy expensive ads to get our name out. We “just” had to be interesting! It might not be easy, but it’s generally free. Aggregators like Reddit, Hacker News, and retweets have accelerated this power even more so recently.

Compare these extraordinary freedoms with just about any other business in the world. Nobody has it as good or are as free as software makers selling via the internet.

All we needed was an idea for a product that people were willing to pay for and the skills to pull it off. Ideas are all around us and the skills are learnable by self study.

You really can create something from nothing.

This is the first in a three part series looking at how we manage Twitter as a support channel. In the parts 2 and 3, I’ll discuss some of the finer points of how we sort through hundreds of tweets each day to get people answers quickly.

Since the launch of the new Basecamp back in March, we’ve been encouraging the use of Twitter as a support channel. On our help form we encourage people with simple questions to use Twitter rather than sending an email, and we monitor mentions of 37signals throughout the day. We’ve always gotten support requests via Twitter and answered them, but it’s only this year that we’ve actively encouraged and focused on it.
Our Twitter presence has grown substantially: in October of this year, 37signals was mentioned an average of 443 times every weekday, roughly double what it was in October 2011. Not all of these need an immediate reply from our support team – many are people sharing links or things that they found interesting. The 60 or so replies we do send a day in response to immediate support requests represent a little less than 10% of our total support “interactions”.
One of the things I spend part of my time working on is how to improve the speed and quality of the responses that we provide to customers, and part of that involves providing advice on the best tools and processes for the support team to do their job. As far as Twitter goes, the biggest pain point is the actual tool used to monitor and send tweets.

The search for a Twitter tool

Since we got serious about Twitter, we’ve mostly used the built in Twitter functionality that our support tool (Desk.com) provides. When I asked the team how it was working for them a couple months ago, the general reaction was tepid. The consensus was that while it gets the job done, it was rather slow to use, and the large number of retweets and links to SvN posts mixed in makes it hard to get people with urgent questions answers promptly. Most of the team was using it, but no one was happy about it.
What did we want in a tool?

This past spring we decided to prune our product line.

We stepped back, took inventory, reviewed how things were growing, considered which products mattered most to us, thought about which direction we wanted to go, talked about what we were proud of, and made some decisions.

This process reminded me a lot of pruning a tree. Before you start pruning, you circle around the tree and take in the shape. You have to step back and get a wide view in order to see the whole thing.

Then you start making some observations.

You notice this branch crossing and rubbing that branch. You see suckers shooting straight up taking energy from the healthy limbs. You see dead wood, you see thriving wood, you see leaders, and you see future problems. And depending on when you’re looking, you might see next season’s buds.

It’s always hard to cut something you grew from scratch. You feel a fundamental obligation to see it blossom and continue to grow strong. You know how long things take to grow, so cutting things back is an emotional process. “Man, this branch has been growing for 10 years and I’m going to cut it down in 10 seconds…”

But you also know that cutting things back means that you’ve favoring what’s left. You pick the winners, you help the tree grow up strong. And most importantly, while pruning gets rid of a lot, it also opens up new opportunities. Light gets in where it couldn’t before. Air circulates better. And new growth comes to life.

Now let’s get back to software.

Initially when we decided to prune our product line, we did it because we felt we had too many products to maintain. We’re bigger than we used to be, but we’re still a small company. It’s so easy to create (because creating is fun), but it’s also easy to ignore (because ignoring doesn’t involve work). Over time, if you create too much and don’t clean it up, you can lose control over quality. Quality, like time, is a limited resource. We felt like we might be on the verge. Hence the pruning session.

So we decided to stop accepting new signups for Ta-da List, Writeboard, and Backpack. We also stopped selling our Draft iPad app. We sold Sortfolio, stopped selling the Getting Real PDF (we’re giving it away for free now), and pruned some internal non-customer facing tech, too.

But an interesting thing happened. Not too long after we pruned, a couple new product ideas started bubbling up. Before pruning, the last thing we were thinking about was adding more products. Now, with some breathing room, new ideas are getting light, getting fresh air, and coming to life.

Not only are we thinking about a few new products, but we’re thinking very differently about these new products. One is a variation on an existing product. And one is entirely new for us. But both are also attached to a new business model.

I feel like our exploration into new business models would have never happened had we not cut some old growth back and let some new light in.

We’re finishing these two new products up now. We aren’t ready to announce release dates or talk much about them yet, but hopefully it won’t be too long now.

So, while it’s hard to cut back, it’s good to remember that subtraction can lead to addition. New shoots, new sprouts, and new ideas often need new room to grow. They’re waiting, but you need to clear the way.

Last month we launched the redesign of our blog. During the process, we wanted to make it feel distinctly ours with a visual nod to its very name—signals and noise.

I wanted our blog to feel special, aesthetically unique, but not gaudy. I took a quick survey of our blog structure and found a great area for opportunity to explore style: our post categories. From design, programming, business, support, writing, to sysadmin, anyone from our team can categorize a post they write.

To give each post an identity, I riffed on these category themes. From there, the obvious presented itself: try illustrating waveforms to harken back to “signals and noise.” Although I had a focus on illustrating, I still started with words, and more specifically, questions to myself.

What does “writing” look like?

So, with Illustrator fired up, I started generating waveforms that would wear the identity of “design,” “programming” and so on. It quickly became an exercise in shape, color, and line densities. The process was fun, and the results were full of surprises.

“Big data” is all the rage these days – there are conferences, journals, and a million consultants. Until a few weeks ago, I mocked the term mercilessly. I don’t mock it anymore.

Not a “big” data problem

Facebook has a big data problem. Google has a big data problem. Even MySpace probably has a big data problem. Most businesses, including 37signals, don’t.
I would guess that among our “peer group” (SaaS businesses), we probably handle more data than most, but our volume of data is still relatively small: we generate around a terabyte of assorted log data (Rails, Nginx, HAproxy, etc.) every day, and a few gigabytes of higher “density” usage and performance data. I’m strictly talking about non-application data here – not the core data that our apps use, but all of the tangential data that’s helpful to improve the performance and functionality of our products. We’ve only even attempted to use this data in the last couple of years, but it’s invaluable for informing design decisions, finding performance hot spots, and otherwise improving our applications.
The typical analytical workload with this data is a few gigabytes or tens of gigabytes – sometimes big enough to fit in RAM, sometimes not, but generally within the realm of possibility with tools like MySQL and R. There are some predictable workloads to optimize for (add indexes for data stored in MySQL, instrument in order to work with more condensed data, etc.), but the majority aren’t things that you ordinarily plan for particularly well. Querying this data can be slow, but it’s all offline, non-customer facing applications, so latency isn’t hugely important.
None of this is an insurmountable problem, and it’s all pretty typical of “medium” data – enough data you have to think about the best way to manage and analyze it, but not “big” data like Facebook or Google.

Technology changes everything

I’m looking to hire an “iOS Prototyper” for one year. This is a full-time, 1-year contract. You must be in Chicago. Pay starts at $100,000 – I’m all ears if you want to make an alternate pitch. After the year is up we may decide to work together some more, but that’s a discussion for another time.

The role is clear: You’ll work with me on a daily basis to explore a variety of iOS app ideas for 37signals. We have a good half dozen ideas in the idea closet already, and more will materialize as time goes on.

This is a distraction-free position. Your only job will be exploring iOS ideas for 37signals. Ideas include new apps, new interface concepts, and a healthy helping of crazy ideas. You’ll report directly to me. We’ll riff, review, and spend time together nearly every day.

This position is for one person. You have to have the Obj-C chops and the design/ui/ux chops to be a one-person-iOS-shop. You have to be strong – and already up to speed – on both.

This is a perfect position for someone who knows how to work fast and smart. You know where the rabbit holes are and you’re good about avoiding them early on. You know which details make all the difference, and which ones don’t make any difference. You know the difference between spending time wisely and wasting time.

You’ll teach me a few things and I’ll teach you a few things. We’ll both gain great experience.

This job is primarily about prototyping, not shipping. Some ideas may ultimately ship, but the main goal here is to explore. You have to be OK with that.

If you’re interested, please email me directly. [email protected]. Since we’ll be working together closely, you must live in Chicago or be willing to relocate to Chicago for at least one year. Creative applications are encouraged.

I’ll be accepting applications until November 30th. I’m looking forward to working with you.

When I started racing cars, I thought it would be great if I could just settle in mid-pack in a respectable gentleman’s cup series. After all, racing to me was all about getting access to long stretches of flow, that sensation of being so completely engrossed in an activity that you lose track of time and place.

It didn’t take long before my ambition swelled, and I upped the goal from finishing mid-pack to top 10. Of course, not before taking a brief moment to bask in the glory of reaching that first goal, enjoying success per my own definition. A definition that would surely have qualified as utter failure for many others (what schmuck is happy to be mid-pack among gentlemen?! At the time, me!).

And thus, the goal creep was on. It crept from top 10, to podium, to moving up to a bigger series, a faster car, more downforce, tougher competition, longer races, a better team, and on it went.

The key is that it was all a bite-sized progression. While the ultimate goal might have been entering the 24 hours of Le Mans (a goal that itself has crept from entering, to finishing, to winning the class), that wasn’t really part of the detailed goal posts that has driven the pursuit forward.

You can think of goal creep as the test-driven development of a real-life pursuit. In TDD, you don’t try to design your entire program upfront. Instead, you just write a simple test and then implement just enough code to make that test pass.

Setting small goals, like writing simple tests, keeps the pursuit from becoming overwhelming. Making the mental jump of going straight from playing Forza Motorsports to getting on the grid at Le Mans is an insurmountable idea for most. It certainly was for me.

But these small, underwhelming goals trick your brain into constantly experiencing a steady flow of success. It’s incredibly important to celebrate these successes, however modest, as they’re the fuel that’ll keep you going and reaching for more.

The same was true when we started working on Basecamp and I was learning Ruby. If the goal had been to create an application used by millions and a framework that would rock an industry, I would never have put down the Xbox controller and gotten started.

Even our economic goals were incredibly modest when Basecamp launched. While others were thinking of millions of users and millions of dollars, we had the goal of making $4,000/month from Basecamp after a whole year.

We met that goal in a couple of weeks and were able to celebrate a success that would have been utter failure to many others. And after a year, when Basecamp made just enough money to pay all the bills and relieve us from having to do consulting work on the side, we celebrated again.

I guess the point is to define your own goal posts. Don’t be so eager to adopt the goals of others. They are starting from a different baseline than you. If you adopt “shoot for the stars,” you might well run out of propulsion before you even get to the yard.