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):

1. It only takes one person to make your product suck.

I love the movie Twelve Angry Men. (The Henry Fonda version, not the Tony Danza version.) It’s about this jury of 13 people, 12 of whom walk into the jury chamber convinced the accused is guilty. But as you know, juries can only render verdicts with unanimous consent, so that one lone individual is able to prevent a quick conviction and force the jury to review the evidence and deliberate on the case—one by one convincing everybody that the accused is in fact innocent. It’s a great movie about the power of the individual to uphold justice in the face of prejudice, expediency, and general carelessness.

Unfortunately, your team isn’t a jury. Quite the opposite: 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.

2. Nobody ever got fired for sucking.

There’s that old saying “Nobody ever got fired for buying IBM”. It dates back to when IBM was in decline after a long period of dominance, when there were clearly superior products available but the risk of choosing them was higher than the safety of going with the tried-and-true. 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. Too often product teams take the the quick and dirty way to get the feature out, or concede to that “one line change” to satisfy some new client. Nobody gets fired for making something merely meet the hard requirements, even if it fails the “soft” requirement of “not sucking”.

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.

3. It’s easier to suck more than suck less.

Sucking is like a tar pit: once you step in, your struggles only pull you in deeper. After you make that one product compromise to satisfy some crazy customer, then you’ve got to support that setting forever lest you lose the customer who depends on it. Then other customers find it (because if you’re going to build it, why not give it to everyone?), and those customers have their own unique requirements that pull you further into the sludge. That one random checkbox for a single customer becomes a full settings page for a niche demographic with esoteric needs. Supporting those customers places constraints on how you support other customers, affects how you upgrade your data structures over time, prevents sharing of certain types of code, etc. The tar pit sucks you down, and sometimes the only way out is to go back the way you came, discarding the customer you fought to get in the first place, and upsetting all your other users along the way. Avoiding the tar pit takes an incredible level of discipline and fortitude. It should be no surprise that it so rarely happens.

Suggestion: Avoid the tar pit at all costs And when trapped—which will happen, often, despite your best attempts—cut off your own limb if necessary to get back on track. Even if it means upsetting 100% of your users: if they’re the wrong users, it’s what needs to happen to get the right ones.

4. There are more ways to suck than to not suck.

Anybody charged with building some feature is immediately overwhelmed with choices. Even ignoring the countless technical options for rendering feature X on platform Y, there are limitless sub-variations to every possible choice. Something as simple as, “Should this link be a button?” “Should the button be on the left or right of this other button?” “Should clicking it open up a dialog or a new page?” “Should you click Save after clicking the button, or does the button auto-save the result?” And on and on. If sucking is like a tar pit, then building a product that doesn’t suck is like walking a tightrope over La Brea. In the fog. There are countless places to step, but very few of them are on the right path—and often you don’t know you’ve slipped until you’re waist-deep in tar.

Suggestion: Define what not sucking means to you, and make sure everybody knows it. Even if the lines are ambiguous, draw them anyway, and work to constantly refine them. How you circle your wagons is far more important than how fast you can fire your guns.

5. 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.

But ultimately, if your users hate your product, eventually an alternative will come along that sucks less. At Expensify, we try to live by these rules and create products that don’t suck. Like any ideals, I don’t claim Expensify lives up to them perfectly. If you’d like a glimpse at what we are working on next and want to help us suck less, please sign up for our Expensify 2.0 Beta.

Most products suck. But yours doesn’t need to, and we’re trying as hard as we can to ensure ours doesn’t either. I’d love your advice on how we’re doing, or any suggestions on how to do better.

0 0

7 7

Authors: Guest Author

to know more click here