Product lessons we can learn from Google+

Una interesante entrada en el blog de intercom nos habla de algunos de los problemas a los que muy posiblemente ha enfrentado Google con Google+.
El autor de la entrada participó en el desarrollo de la herramienta y saca unas conclusiones que me parecen extrapolables al diseño de producto en general:

1. Build around people problems, not company problems
There is so much room for invention, so much opportunity to make people’s lives better, the Internet is in its infancy. There is no need to worry so deeply about competitive threats, as if it is a zero sum game and there is a foregone product conclusion.

2. Perceived benefits need to be greater than perceived effort
My mobile phone’s address book is full of people I don’t recognise. It is a pretty comprehensive list of all the people in my life, yet woefully managed. One of the most personal parts of my most personal device is full of strangers. This is the same for almost everyone and the reason is simple: it’s not worth the effort to keep it up to date.

3. Ruthlessly focus and descope, be patient, the internet is young
This lack of focus adds huge complexity to the product, and huge cognitive effort on the parts of users, therefore increasing the effort required. All of the massively successful social products of the last few years have started out by doing one thing really well, then growing organically and expanding.

4. Embrace the idea that life is messy
There is a deep dichotomy between this messy reality and software builders’ desire for structured data. Maybe someday we’ll figure out that our brain is all nodes and links, deep and shallow pathways between objects, and we can directly map to it with software. But likely not in our lifetime.
…Much of WhatsApp usage is group conversations but the subtle, critical difference is that these groups are typically not permanent or sustaining. It is not a stable set of people discussing multiple things in sequence over time. It is one-off combinations of people grouped together for something temporal, like an event, a concert, a party, a weekend away. The groups then decay gracefully. When necessary they are rebuilt from scratch.

5. A fast follow product strategy doesn’t work when you have network effects
There is a nightclub close to our office. It’s pretty run down, it plays questionable music, it serves questionable beer. And it’s packed every night. People love it. Many new nightclubs have opened up next door, only to close their doors months later. They had better decor, better music, better beer. But they didn’t have the one thing necessary for success: people’s friends. People want to be where their friends are, and this trumps everything.

Network effects take time to build. This requires an entirely different product strategy than fast follow. And it requires patience and focus.

6. Google+ suffered shiny object syndrome
…I’m sure there was a ton of legacy to deal with here, but you have to wonder about what might have been if an identity layer had simply been applied across all these products and they were invested in. The same way Google applied a consistent visual design across all its products.

7. People need clear conceptual models that exist in real life
…Looking back at the history of communication, most successful social software has an analogous offline experience. Even something like a Newsfeed can be easily compared to a local town square as the primary source of news and gossip. With a new tool, people need an established way of thinking about it to reduce the perceived effort of use.

8. Distribution often trumps product
…If the goal was to get hundreds of millions of people signed in to Google every day then it looks like it achieved that. Whether knowingly or unknowingly, an order of magnitude more people are now signed in under one identity, searching, emailing, watching videos. Once you have distribution … there are many paths to success.

So what to do next?
…go back to absolute fundamentals and have ruthless focus. Remember that product strategy means saying no. …
Simplify the product offering by killing features, and lowering the effort required to get value out of it by killing many of the choices in the UI.
Finally, and most importantly, it needs to build upon established real world … conceptual models.