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

File:DiffusionOfInnovation.png

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.

Comentarios

  1. Hola Ernesto, ¿cómo estás?

    37signals nos tiene acostumbrados a artículos que sintetizan conocimientos teóricos y prácticos de nuestra actividad, de una forma que a mi me resulta espectacular, por el balance entre el punto de vista de negocio vs el punto de vista del profesional, a la vez que la estructura del artículo lo hace super-didáctico.

    Coincido contigo en que no hay una postura dominante sobre la cuestión de innovar o no, a pesar de que la infografía transmite el concepto del ciclo de vida de innovación de un producto de forma efectiva (y es muy muy atractiva visualmente).

    Desde mi punto de vista, quien siempre está a la vanguardia generalmente no logra desarrollar un producto que se comercialice bien, porque estar a la vanguardia y generar un producto bien comercializable exige un enorme esfuerzo de I+D (investigación + desarrollo). Esto bien lo sabe quien ha hecho sus 1ras armas como entrepreneur o ha debido administrar el presupuesto anual asignado por la compañía para desarrollar las actividades de su sector.

    Lo anterior desde ya está sujeto a debate, porque innovación vs facturación nos lleva a evaluar múltiples factores que afectan al desarrollo del producto en cuestión, tema que podría ser un post en si mismo, con muchísimos comentarios al respecto.

    Como conclusión, en mi experiencia la innovación no siempre es necesaria para comercializar bien un producto, y a la vez se hace necesaria cuando ciertas condiciones del mercado hacen perder competitividad al producto en cuestión, como por ejemplo:

    a) El atraso tecnológico: arquitectura y diseño del sw, lenguaje de programación, plataforma e infraestructura requerida, etc.

    b) La adopción de ciertas funcionalidades, que antes se podían considerar "especiales" y ahora los consumidores del producto las consideran "estándars", como decir: todo producto de xxx línea, si no tiene tal y cual función "de fábrica" entonces "le falta" y sigo buscando.

    c) "Refrescar" el look & feel del producto, haciendolo Web 2.0 o 3.0, por ejemplo. Podríamos considerar este punto como un caso especial del punto a), pero como detrás de dicha mejora hay un montón de tecnologías (html5, css3, jquery/json/ajax/javascript, etc.) creo que vale la pena evaluarlo aparte.

    Seguimos pensando... siempre!!
    --
    GS

    ResponderBorrar
  2. Hola Ernesto,

    Tu post me hizo pensar en varias cosas. Una es que la capacidad de innovación no es igual a la de actualización. Un software inmaduro necesita actualizaciones todo el tiempo. Un software innovador no (quiero decir, no necesariamente). Dicho de otro modo, la actualización constante puede ser un signo de inmadurez, no de innovación. Incluso la innovación a veces trae más generalidad (la misma idea aplicada a más situaciones) y menos complejidad (elegancia).

    Los equipos de desarrollo chicos pueden aspirar a construir software que sea innovador, sofisticado y maduro a la vez. A un equipo muy numeroso no le queda otra que seguir metiendo más código, tanto para emparchar lo que todavía no anda como para agregar nuevas features que contrarresten la falta de generalidad. Para ellos la actualización es siempre un problema porque rompe lo que (no sabemos bien cómo) venía andando.

    ResponderBorrar
    Respuestas
    1. Leandro,
      Primero qué bueno tener comentarios tuyos en el blog! :-)

      Luego, es cierto. El ritmo de actualizaciones puede explicarse o entenderse a partir del nivel de madurez del producto. De hecho en el libro de estos muchachos comentan que su política es salir rápido, aún si están crudos, para luego depurar o mejorar en función del feedback. Ese es un lujo que pueden darse los productos jóvenes. Los productos con más recorrido tienen una comunidad de usuarios que usar, y también muchas más cosas que "romper sin querer".

      Seguimos pensando..

      Borrar

Publicar un comentario

Muchas gracias por comentar. Por favor deja tu nombre y/o email, los comentarios son mucho más valiosos cuando se sabe quien los hace.

Entradas más populares de este blog

10 definiciones de calidad

¿Qué es time and material?

Teoría Económica y Outsourcing