Why Products Suck

I found the following article on TechCrunch. It was written by David Barrett, CEO and founder of Expensify, whose tagline is “Expense reports that don’t suck.” As I read it, I couldn’t help but see the obvious relevance to the church world, and so I’m posting a portion of the article. See if you agree…

Now, you might think that making a product that isn’t terrible should be so obvious to every company on the planet as to almost be nonsensical. Indeed, who would ever advocate building a product that sucks? But the fact is: many products do suck. How can something so obviously important and universally recognized by so infrequently accomplished?

It’s a surprisingly complex question. But I think it all boils down to variations on a single, simple answer: it is much, much easier to build a product that sucks than one that doesn’t. Here are some reasons why that is true (and what you can do about it):

It only takes one person to make your product suck.

Anybody can make your product suck, often without anybody else noticing until it’s too late to change, and very expensive to undo. The fastest racecar can’t move if the gas-cap gets stuck; your product is only as good as its worst component. Not sucking requires continuous, unanimous consent—not on the details, but consent that not sucking is worth the effort. And you need to do it without security guards lurking outside the door.

Suggestion: Convey to your team and the world that not sucking is your primary goal. More important than new features, more important than new customers—even more important than being awesome—is the simple act of not sucking, consistently, across the board. Each awesome feature might attract a new user, but each sucky feature will lose you two.

Nobody ever got fired for sucking.

You can always be fired for something going horribly wrong, or for trying something crazy that doesn’t pan out, or for doing something that upsets a key customer or loses a major deal. But nobody gets fired for merely doing something sub-optimal, especially when that’s what everybody else does.

Suggestion – Be slow to hire, and quick to fire. I know everyone always talks about the importance of exceptional people. But like the importance of not sucking, that standard is very rarely maintained in reality. Maintain it. There’s that saying “A people hire A people, B people hire C people.” Be an A person, even if it means doing without for far longer than you’d like.

Customers demand sucky products.

Not intentionally. But they request features that make your product suck, with depressing regularity. This is doubly true if your product allows some users to manage other users. There are features that they think they need but don’t, and features they actually do need but nobody else does. There are billions of people out there and you will never, ever satisfy even a tiny fraction of them. So be very selective as to which ones you let dictate your roadmap, and make sure they’re taking it to the promised land and not into a tar pit. They’ll threaten to never use you, or to quit, or to say bad things about you. Some will actually follow through. But most will eventually realize you were right all along. That is, if you actually were right in the first place.

Suggestion: Trust your instincts and the tiny set of users who use you, and resist advice from the billions of people who don’t. Either you’re right or you’re wrong. If you’re right, sticking to your guns will lead to success. And if you’re wrong, better to fail fast on your own merits and learn something along the way than to take bad advice from people who never intended to use you in the first place.

Don’t get me wrong: people complaining about your product isn’t all bad. People only complain about things that matter to them; better to have complaints than disinterest. And not all complaints are equal: complaints that you don’t support feature X are far better than complaints about how feature Y sucks.

Entire article here.

See any relevance to the “business” of doing church?

Posted by | 13 comments