Pages

Monday 8 September 2014

Why You Need To Build Opinionated Products

Any product worth its salt was built for one of two reasons. The first reason is more evident and intuitive to understand - fulfilling a need. Picasa made online picture sharing and storage a piece of cake just when users around the world were struggling with limited email attachment size to send photographs to friends and family. The second bucket of products create the need in a bid to then make the product an indispensable part of their users' lives. Nobody had a sudden urge in the middle of the night to write about pickled lemons in 140 characters or less. Twitter created that need.

Products always start out with a vision - a plan and a purpose - yet it is fairly common to see them change course and meander off into an unintended path. And that's okay. That's okay provided the new, end-product is a derivative of your opinion, your reading of usage and your vision. Product folks often make the mistake of listening to all their users, especially ones with conflicting usage patterns, leading to pages and pages of knobs and settings. An interesting analogy can be drawn between products and rivers. As long as both power through one path, they are strong and booming. The path may deviate from the originally intended course, but if everything holds together, the river will meet the ocean at full capacity, just as the product will hit users with the same force. A product with a hundred different configurations is, however, like a river with a hundred tiny distributaries - each is weak, sluggish and in a lot of cases, may die out before meeting the ocean.

Non-opinionated products are riddled with settings and configurations. They do not define the 'golden path' that they want their users to follow but leave most of the of flexibility to its users. Users are expected to turn knobs and dials to reach a product state that they believe fits their need and then find value in the product. The problem with this approach is that no product is optimized for every permutation of its settings. The chosen permutation may be lacking in a lot of functionality and leaves the user wanting more. Satisfying this need leads to the introduction of more settings in the product to support the 'distributary'. It is indeed a vicious circle and no product person wants to be in that state - after all, every setting turned on or off makes for a different product, and maintaining all those products leads one down an endless rabbit hole.

Leave out the fluff. Kill all those settings. Build opinionated products. 

Proponents of non-opinionated software often claim that it is arrogant for product to ignore feature requests and that software should be as flexible as possible. Here's what 37Signals, now Basecamp, had to say about that in an article:
We think that's bullshit. The best software has a vision. The best software takes sides. When someone uses software, they're not just looking for features, they're looking for an approach. They're looking for a vision. Decide what your vision is and run with it.

Building opinionated software does not mean you are not listening to your users. It does not mean you disregard any feedback that comes your way or turn a blind eye to popular usage trends. It means listening to them to find out their biggest points of friction, focusing on the problems your product intended to solve all along and providing that must-have experience for users. 

Saying 'no' can be hard - especially for people who live to build products for users. It's important to remember that although a lot of users will not like it, the ones who do, will love the product, will stick around the longest and be the strongest advocates you'd ever find.