Making software smarter sometimes pushes customers away

A colleague and I were talking about how MS Project tries to anticipate, intuit, and proactively rearrange your project plans for you--and how often this goes wrong and just ends up frustrating us to the point of doing what we were doing at the time: looking at a simple gantt chart I'd built and shared with her on a competitor's product (in this case smartsheet.)

We have to be careful about how we try to make software "smarter". Done wrong, we can make the user feel too dumb to use it and drive them away.

37signals is famous for (among many other things) their approach of deliberately trying to "underwhelm" the competition by doing less, saying no to most feature requests, and keeping things so simple, so clear, so easy-to-use, so mission-focused that it does its job REALLY well and that's it.

Think about your phone. I was talking with a gentleman the other day who'd just bought a smartphone and realized after a week it was way too much for him; he was complaining about how hard it was to find a phone that was literally just a phone.

It's okay to put all kinds of sophisticated intelligence in our software. Enterprise-class problems are complex and require a solution that fully addresses each need. But we need to keep in mind the old Naisbitt idea of High Tech/High Touch and ensure we spend at least as much brain power on making it usable and friction-free. "Smart" shouldn't just mean logic and rules and number crunching on the back-end; it should mean we've arrived at the simplicity on the far side of complexity in our interface. Sometimes it just means let me do it myself, thank you very much.

Software is like Tic-Tac-Toe

We just taught our three-year-old son how to play tic-tac-toe. I was in the beginning stages of the very lengthy porcess of putting him to bed the other night, and we were taking turns drawing on a little refreshable drawing pad when I drew a tic-tac-toe board. We played a few games. Then it was his turn to draw and he decided to draw a "better" tic-tac-toe board with more lines on the playing board so you would have to get five in-a-row to win instead of three. I chuckled because I remembered doing the same thing as a kid. But it occurred to me that traditional tic-tac-toe where three in-a-row wins was, in fact, the best (and maybe only really usable) version of the game. There is an optimal point where you hit "enough" and putting more complexity into the game makes it worse and sometimes not even worth trying to play.

The company 37signals has been an advocate of this same idea in software for some time: a given application should be about getting certain things done. The developers should find the easiest, fastest, most intuitive way to do just that and stop. Adding more lines (in this case, lines of code) to the game does not make it better. It buries the core functionality so that the software becomes too complicated, too hard to find the function you need in all the drop down menus, too much of a hassle. And we wonder why user adoption is so hard. I think the winners are those, like 37signals, who find that point of "enough" on the curve and deliberately stop while they can.