¿Debería publicar el #consultip "no actualice [su producto] en vano"?

Hace unos días recibí un comentario de un amigo que me pareció interesante. 

Decía que "hay una marcada necesidad en los productos de software (estilo dropbox, facebook, skype, etc) de mostrarse en constante actualización" y también que en muchos casos eso es malo porque hace perder a los usuarios confianza en el producto.  

De hecho, a esta altura ya se lo notaba enojado, decía que deberíamos pensar en un consultip que dijera "no actualice en vano" (aquí entre nos, él lo decía de otra manera pero yo elegí copiar a Dolina en la forma de escribirlo).

Lo primero que pensé es que no todos piensan así. Por ejemplo, la gente de 37signals piensa tan distinto que en su libro Getting Real, que mencioné en este post, dicen que hay que “construir menos”. Tienen un apartado llamado así donde dicen:

Conventional wisdom says that to beat your competitors you need to one-up them. If they have four features, you need five (or 15, or 25). If they’re spending x, you need to spend xx. If they have 20, you need 30.

This sort of one-upping Cold War mentality is a dead-end. It’s an expensive, defensive, and paranoid way of building products. Defensive, paranoid companies can’t think ahead, they can only think behind. They don’t lead, they follow.

If you want to build a company that follows, you might as well put down this book now.

So what to do then? The answer is less. Do less than your competitors to beat them. Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else. Instead of oneupping, try one-downing. Instead of outdoing, try underdoing.

We’ll cover the concept of less throughout this book, but for starters, less means: Less features, Less options/preferences, Less people and corporate structure, Less meetings and abstractions, Less promises.

Luego recordé también el libro Crossing the Chasm de Geoffrey Moore. Allí fue donde tomé contacto con el ciclo de adopción de la innovación (la imágen es de wikipedia) y con esta idea de que a los usuarios de tecnología no se les habla a todos igual pues, según en qué parte del ciclo están, quieren cosas diferentes.

Si bien me gusta la postura extrema de 37signals, también creo que no hay una estrategia dominante para todos los casos/productos y que debemos entender para quien estamos haciendo el producto antes de decidir la nuestra. En algunos casos tendrá más valor para el usuario “sumar funcionalidad constantemente” (innovators) y en otros “mantener interfaz y estabilidad” (laggards).

En realidad la cosa es peor porque para determinados productos conviven distintos tipos de usuarios. Es por eso que vemos que los cambios de interfaz de Facebook son paulatinos y siempre asegurando que el que quiera, por un tiempo, puede seguir usando la vieja forma de ver las cosas.

Entonces, dicho todo esto, ¿ustedes qué opinan? ¿Debería o no publicar el #consultip "no actualice [su producto] en vano"?

Seguimos pensando..

PD: Nada de decir depende que a los tibios los meten en el freezer o en el horno.