We have an idea we’d like to try with a few folks who think they could be good at pitching Highrise.

I’m not sure if we’d call the idea a reseller program, affiliate program, or a partner program, but we do think it will be a great opportunity for you to make money selling a product that often sells itself.

If you’re a reseller or a salesperson or someone who thinks they can get Highrise in front of the right people, drop us an email at svn [at] 37signals.com and include “37signals Affiliate” in the subject.

We’re going to be selective and only pick about 10 companies/people to work with on this program so serious inquiries only please. Thank you.

The Onion comes through, as usual. Don’t miss the scrolling ticker at the bottom of the video too.

Poll: Bullshit Is Most Important Issue For 2008 Voters

Khoi, who’s consistently one of the best writers on the web, recently took a swipe at enterprise software. Who can blame him? We agree.

If you work at a big company and you’ve ever had to do something that should be simple, like file an expense report, make changes to your salary withholdings — or, heck, if you’ve ever tried to apply for a job at a big company — then you’ve probably encountered these confounding user experiences. And you probably cursed out loud.

Then he opines:

I have to wonder: what is it about the world of enterprise software that routinely produces such inelegant user experiences?

My take: The Buyers Aren’t the Users

The people who buy enterprise software aren’t the people who use enterprise software. That’s where the disconnect begins. And it pulls and pulls and pulls until the user experience is split from the buying experience so severely that the software vendors are building for the buyers, not the users. The experience takes a back seat to the feature list, future promises, and buzz words.

This is one of the reasons we think enterprise is a dirty word. It’s also why it’s an absolute pleasure to design products for what we call the Fortune 5,000,000.

The Fortune 5,000,000 are the the small businesses, the side-businessess, the freelancers. The people who buy our products are the people who use our products. If they don’t get value on both the financial side and the productivity side they don’t stick around.

We have to make the money happy and the people happy. In our market they’re the same person. In the enterprise market they are often different people in different departments in different buildings who sit at different lunch tables.

In the world of small business software the product — not the salesperson — does the talking. There’s no camouflaging value when the buyer is the user.

Rory asks:

Is there any hope for designers in the online entrepreneur world? As in, people who can for concepts sketches and design layouts, but who can’t program themselves? Or would you say that the ability to program is an absolute must?

I’m a designer who can’t program worth a shit. But I’ve always loved designing interfaces and I’ve always loved building a business. With passion, curiosity, and ambition, there is always hope.

Getting started

I got started by designing text-only interfaces for BBS’s way back before the web. Then I moved to graphical BBS’s when NovaLink Pro was introduced. Then I moved to making music, book, and video organizers in FileMaker Pro. FileMaker Pro allowed a designer to make a product with barely any understanding of programming. Just pop in some fields, set up a few buttons, add a few conditions, and wrap it in a nice UI.

Audiofile in FileMaker

My first foray into product-based entrepreneurship was a shareware product I built in FileMaker Pro called Audiofile. Audiofile was $20 and I uploaded it to AOL. This was the early 90s. A few weeks later my parents gave me an envelope with my name on it that came in the mail from Germany. I didn’t know anyone in Germany. I didn’t know what to do with it. But when I opened it there was a crisp US $20 bill wrapped in a printout of my Audiofile order form. That was my first customer and the moment I realized I can do this.

So over the next few years I released a few other products. BookBin for organizing your books, Videofile for organizing your videos and DVDs. The $20 bills came flooding in. It was really exciting. It bought a lot of beer (and other stuff, ahem) in college.

I met a lot of folks and made some great lasting business contacts through my FileMaker Pro products. Richard Bird, now a great friend and colleague, was one of my first customers. Richard even hired me to design an experimental (and vaporware) project management tool called Sightrope. This was probably around 1999.

Every once in a while I hear from Basecamp customers who connected the dots all the way back to Audiofile. They were Audiofile customers back in the day.

Singlefile on the Web

Eventually I wanted to move these products to the web. I had tired of using FileMaker Pro and tired of building software people had to download. I wanted to build web-based software. I decided the first product I’d take to the web was BookBin, the book organizer. I decided to rename it Singlefile (wayback machine archive).

So I started learning PHP. I never took any programming classes or went to school for any of this. I just got a book on PHP, followed the examples, and wrote some code. It was shitty code, but it mostly worked. But I was stumped. I couldn’t figure out pagination.

Enter David

So I wrote a post on SvN asking for some help. I got a lot of responses, but the best one was from this guy named David Heinemeier Hansson. He was friendly, helpful, and patient. We traded some emails and then I decided to hire him to help me with Singlefile. This was when David was a PHP programmer, a few years before he even discovered Ruby. Remember that?

David and I got along well, our working styles meshed, we both enjoyed swearing, and our general outlook on simple software was the same. So we did a few client projects together. And then we started on Basecamp. The rest is history.

You can do it

Yes, there is plenty of hope for a designer who wants to build a product business. Having business sense will help. Being able to spot and attract other talented people will help. Having a knack for spotting the right opportunities will help. But being curious enough to just figure things out on your own will help the most. If you can’t program today it’s because you haven’t tried to learn yet. Just a little effort may pay serious dividends down the road.

Who knows where things will lead. My story started with designing text-based interfaces for BBS systems.

So, yes, you can definitely build something great if you’re “only a designer.”

Got a question for us?

We’re looking for interesting questions to answer here at Signal vs. Noise. Got one? Then send it to us at svn@37signals.com (make sure the subject line reads “Ask 37signals”). We’ll cherry pick the most interesting ones and answer them here. Fire away!

A few months ago we launched the Items Anywhere feature in Backpack. This allowed you to move content anywhere on the page. You could have a file then a to-do list then a note then another to-do list, etc.

Good, but…

People loved this new functionality, but it introduced some new behavior into Backpack that turned out to be more frustrating than we thought. The issue was this: As part of the new Items Anywhere feature, you had to add new content from the top of the screen. You could move anything anywhere you liked, but it had to be added at the top first. Then you could move it somewhere else. This made adding and positioning a two-step process. Annoying, yes.

So now what?

We started brainstorming, sketching, and considering some options. How could we keep the Items Anywhere feature but also allow you to add content anywhere? How could we do this without making things more complicated or without adding a lot of interface overhead?

First idea: Add from the bottom too

We had a fair number of requests from people who didn’t mind adding content at the top of the screen, but they also wanted to add content to the bottom of the screen. This seemed like a reasonable request, but it didn’t solve the more common problem: How to add content to the middle of a page. Adding content to the top or bottom still required you to move the content after you created it. So we passed on that solution.

Eureka in a chat

I pinged Sam regarding this “widgets to add content under a page separator” feature we’d been loosely discussing. We tossed around a couple of options: Adding content from a divider and adding content anywhere via a hover in the gutter between items. Sam’s “add anywhere via a hover in the gutter” concept seemed like the best idea, but we tried the divider option first since it was the easiest (“Judo”). Here’s the chat transcript:

I’m on the left, Sam is on the right

Continued…

“The hole and the patch should be commensurate.”

Over the past few months we’ve been getting requests from professors around the country inviting us to speak to their business, design, or engineering students about Getting Real.

So we’ve been thinking about putting together a 37signals Getting Real College Tour. We’d pick a dozen or so schools and put together a speaking tour over a couple months.

If you are a professor and you think you can pull together 100+ design, business, or engineering students to attend a one or two hour talk (including Q&A) on your campus, please drop us an email at svn@37signals.com.

Important Note: Since we posted this we’ve been hearing from a lot of students. It’s great to hear that you’re interested, but in order to make this work we’ll need to be contacted by professors or department heads who would be able to sanction/sponsor the event. If you’re a student please let your professor/department know you would be interested in having us speak at your school. Please ask them to get in touch with us directly. Thanks!

We look forward to hearing from you.

The third match in 2007’s Layer Tennis season is underway between Steven Harrington and Chuck Anderson. It’s the best one yet.

Pablo Fernandez asks 37signals:

Do you really think is the lack of features what makes a software better, or is it the “illusion” of simplicity (hiding the less used features, and emphasizing the common ones).

I don’t think the number of features is what makes software better or worse. One more or one less isn’t really the issue.

What matters is the editing. Software needs an editor like a writer needs an editor or a museum needs a curator. Someone with a critical eye and the ability to say “No, that doesn’t belong” or “There’s a better way to say this.” Physical constraints create natural limits for books and museums. Books have pages and museums have wall space. Software, on the other hand, is virtual, boundless. Anything is possible. When anything is possible someone inevitably tries to make something do everything. And the more something does the harder it becomes to understand, grasp, and use. So the key is deciding what makes it and what doesn’t. This applies both globally (the entire inventory of features) and locally (what someone can do on the current screen they’re looking at).

It’s not about ten features versus seven, it’s about the right four versus the wrong eight (or the right eight versus the wrong four). It’s also about the right place and the right time to reveal the right features. Every feature, widget, or interface control competes. Loading up the screen with stuff that is used 10% of the time means the stuff that’s used 90% of the time has to fight for attention. That’s not a good experience. The experience should be light, flowing, and comfortable, not heavy, clunky, and frustrating.

Software is a recipe: Too much of any ingredient can throw off the balance. The wrong ingredients can spoil a dish. Great software is perfectly seasoned—just enough salt, just enough pepper. Too much of any one thing, or not enough of another, and you’ll send it back.

When we talk about Less Software we’re really talking about balance. We’re talking about finding that sweet spot that solves most of the problem with the simplest solution. Simple for you to develop, maintain, and support, and simple for your customers to derive maximum value with minimal effort, learning, and hassle. From Getting Real, the book:

The key is to restate any hard problem that requires a lot of software into a simple problem that requires much less. You may not be solving exactly the same problem but that’s alright. Solving 80% of the original problem for 20% of the effort is a major win. The original problem is almost never so bad that it’s worth five times the effort to solve it.

It’s not so much about consciously saying “we have three too many features here” it’s about saying “let’s solve most of this problem with less code and simpler design.” If we need to solve more of the problem later we can, but let’s solve most of it now—and quickly. And most of the time the partial solution is the plenty solution.

So remember: Good software is about balancing value and screen real estate and understanding and outcome. If it takes 20 good features to get there, then great. If it only takes eight, even better. It’s not the number that counts, it’s the balance.

Got a question for us?

We’re looking for interesting questions to answer here at Signal vs. Noise. Got one? Then send it to us at svn@37signals.com (make sure the subject line reads “Ask 37signals”). We’ll cherry pick the most interesting ones and answer them here. Fire away!

A quick last minute upcoming speaking engagement: I’ll be on the Business Model Refinement panel this Friday from 4-5pm.

This panel is part of the TiECON Midwest conference at the Hyatt Regency in Chicago on October 5th. Tickets are $50 for TiE Midwest members and $75 for non-members.