Product Management: la maniobra del Loco Iván

Conoce que es la maniobra del Loco Ivan en product management o gestión de producto y como modelar tu roadmap con ella.

scroll

El product management o gestión de producto es, en teoría, relativamente sencillo: documenta todos los requerimientos de las partes interesadas y prioríza teniendo en cuenta el coste de desarrollo y el valor aportado. Este genial y awesómico vídeo del genial y awesómico Henrik Kniberg lo explica en 15 minutos que son ORO PURO:

Pero La Realidad es bastante molesta y suele estropear el escenario perfecto que se dibuja en el vídeo de Henrik. En el Mundo Real, no es tan sencillo determinar el coste de desarrollo de cada funcionalidad ni mucho menos el supuesto valor aportado a los usuarios finales.

La cosa se complica aún más si incluyes actores suplementarios en el ciclo de desarrollo de tu producto, pero claves para determinar el éxito del mismo: tu competencia.

Gestión de producto teniendo en cuenta a tu competencia

La competencia es una de las principales guías para que los Product Managers definan la estrategia de producto. El problema es que, en algunas ocasiones, no es fácil determinar quien es realmente tu competencia. Aunque tu producto comparta el dominio funcional de otro, puede que se dirija a otro segmento del mercado, que se comercialice en un ámbito geográfico diferente o, simplemente, te IGNOREN porque no te consideren importante.

Algo que distinguirá a tus verdaderos competidores es que, les costará concebir un feature complete que no incluya tus principales características y les permita defenderse en las temidas matrices comparativas de funcionalidades.

Matriz comparativa por funcionalidades de producto
Matriz comparativa de funcionalidades

Esta estrategia se basa en dos premisas, cuanto menos, discutibles:

  1. El usuario medio es tonto y, por lo general, desconfiado. Así que, si no le damos todas y cada una de las funcionalidades de las que dispone en el mercado -aunque no las utilice ni las necesite- no va a apreciar el valor añadido de nuestra herramienta ni va a saber como compararla.
  2. Es más fácil vender una funcionalidad que ya existe en el mercado en vez de tener que explicar las ventajas de una nueva.

¿Cómo saber si alguien está intentando replicar nuestro roadmap? ¿Cómo defender tu diferenciación de la competencia? Una de tus opciones es hacer un Loco Iván.

La maniobra del Loco Iván

Durante la Guerra Fría, los submarinos soviéticos no disponían de los potentes sonares de cola que montaban los submarinos americanos. Eso hacía que tuvieran un ángulo muerto en su popa, donde el ruido producido por sus hélices y maquinaria de propulsión les impedían registrar la presencia de otros navíos.

Para detectar submarinos enemigos ocultos en ese ángulo muerto, los rusos practicaban una estrategia denominada Loco Iván: cambiar bruscamente de rumbo -a veces, hasta 180º- para detectar a cualquier posible perseguidor…algo que también podemos probar en nuestra estrategia de product management.

Maniobra del Loco Iván
La maniobra del Loco Iván explicada para Samurais del código

Un ejemplo: el Loco Iván en Otogami

Otogami aun está construyéndose como producto. Con un marketing de baja intensidad y sin apenas labor comercial, aún no somos una competencia más allá del mercado nacional. Sin embargo, nos sorprendió comprobar que otra web de búsqueda y comparación de ofertas implementaba una de nuestras funcionalidades únicas. ¿Casualidad o persecución? Había llegado el momento de hacer un Loco Iván.

Nuestro brusco giro de timón se denominó Otoscore, una puntuación dinámica de videojuegos basada en la calidad/precio, más allá de la calificación de la prensa especializada que obtuvieron en su lanzamiento.

Ejemplo de Otoscore
El Otoscore en todo su esplendor

Aunque hayamos decidido hacer público nuestro roadmap, el Otoscore no era algo que nuestra competencia pudiera esperar, ni mucho menos copiar. Primero, porque no es, ni mucho menos, una funcionalidad clave para la búsqueda y comparación de ofertas. Segundo, porque no existe nada parecido en el mercado.

Y sí, ha sido una maniobra más que arriesgada, ARRIESGADÍSIMA. No sólo porque dedicar tiempo y recursos a algo que no genere ingresos directa e inmediatamente es duro para una startup, sino porque no teníamos NI IDEA de como iban a recibir los usuarios una funcionalidad que no habían pedido. Cabe la posibilidad de que tengamos que tirar todo el desarrollo a la basura.

Product Management a lo Curro Jimenez

En realidad, tomar la decisión de hacer un Loco Iván fue bastante sencilla. Luchamos con tal desventaja de recursos contra competidores extranjeros, que la única estrategia posible es ser absurdamente osados. No es una queja ni un lloro, sino una explicación de porqué, mientras otros prefieren jugar a ser Steves Jobs de todo a 100, nosotros hemos decidido aplicar tácticas de Curro Jimenez. Hay que golpear duro, de forma inesperada y con todo lo que tengas. Sin reservas. No queda otra.

Afortunadamente, por el momento, parece haber funcionado. Nuestros usuarios han recibido el Otoscore con estusiasmo y, ahora, disponemos de una nueva funcionalidad de la que carece la competencia. Si, de verdad, alguien pretende replicar nuestro roadmap, tendrá que dedicar tiempo y recursos para conseguirlo, pero, sobre todo, tendrá que descubrirse como competidor ¿Quién persigue ahora a quién?

  • Alberto

    Hoy me he debido levantar torpe porque la verdad es que no tengo nada claro que es lo que querías transmitir en este post. Más allá de hablar de otogami y del otoscore, por supuesto.

    Para mi lo primordial del product manager es que tenga una visión, que puede ser correcta o no, pero que la debe tener. Por supuesto que debe mirar lo que hace la competencia, pero lo importante no es el “qué”, sino el “por qué”. Debe entender por qué sus competidores están haciendo algo y ver si es algo que simplemente “hacen porque pueden y deben copiarlo”. Si todo lo fían a una matriz de comparación mal vamos.

    Lo mismo ocurre con el feedback de usuarios y clientes que hemos hablado en otras ocasiones. Que deben servir para afinar tu camino, no para dirigirlo.

    En *mi* modesta opinión, claro.

    • Intentaré hacer un resumen: como Product Manager debes tener una visión, por supuesto. Y de la competencia, debe interesarte por qué hace las cosas, no el qué.

      Pero es que, la maniobra del Loco Iván no está destinada a dirigir tu estrategia de producto, ni mucho menos, sino a ayudarte a descubrir y calificar a esa competencia.

      Más allá de la teoría, a veces no es tan fácil saber QUIEN es tu competencia y estudiar que está haciendo. Bien porqué no tienes recursos para poder comprobarlo cada cierto tiempo, bien porque hay muchísimos competidores que analizar (ayer, por ejemplo, descubrí http://www.precioconsola.com gracias a… mi suegro).

      Respecto a la estrategia de producto basada en las matrices de comparación, creo que mi opinión queda clara en el artículo… 😛

      • Alberto

        El caso es que no creo que la maniobra de Iván el Loco aplique a lo que cuentas. Lo que hacían los rusos era suplir una carencia de la única forma que podían, no definir sus nuevos radares, ni mejorar sus submarinos.

        Si para identificar competencia creas una nueva feature en tu producto que no sirve para nada serías tan mal jefe de producto como esperas que lo sea el de tu competencia al copiarlo tal cual.

        Vuestro otoscore para *mi* (como alguien totalmente ajeno al mundo de los videojuegos) me parece que no es una maniobra de distracción, sino que es una muy buena feature porque (casi) toda la información “caduca” en un momento u otro. Ya sea en el mundo de los videojuegos, en la economía o incluso en la programación. Si tú lo ves como una maniobra de distracción es que *en mi opinión* has tenido mucha suerte XD.

        Lo que habéis hecho con esto es mejorar vuestro producto y si un competidor lo copia, debería entender porqué lo habéis hecho. Dada vuestra línea de negocio yo lo veo un acierto y que os acerca a vuestro público objetivo. Si la competencia lo copia sin entender por qué tendrá un problema.

        Por cierto. NO creo que precioconsola sea competencia vuestra.

        • Daniel López

          No solo concuerdo con Al, si no que además… ¡¡¡No has mencionado “La caza del Octubre Rojo”!!!

          Quizá no sea esa la intención pero da la impresión de que hablas de crear cosas “a lo loco” a ver si alguien te las copia y “se descubre”.

          Otra opción es descubrir la “competencia” como se hace ahora y arrastrar una sonda de sonar más allá del motor y las hélices 😛

          • Estuve tentadísimo de poner el coro soviético de la película… ^_^

        • Vale… lo confieso, ni tanto ni tan poco ^_^

          No podemos PERMITIRNOS hacer algo que sea, simplemente, una maniobra de distracción… es verdad, así que, confieso que teníamos fundadas sospechas de que el Otoscore iba a ser muy bien aceptado y que tiene mucho más recorrido que una mera maniobra de distracción 🙂

          Pero… TU, Alberto, sabes MEJOR QUE NADIE 😉 que esa feature no es crítica para lo que aparece en el horizonte de Otogami, convertirse en un servicio más que una web.

          Así que, por un lado lo tomamos como una muy buena feature que nos hacía proporcionar un valor añadido único y, por otro, como una sonda exploratoria, un Loco Iván, que nos hiciera ver si alguien estaba en nuestro ángulo muerto.

          Yo tampoco creo que precioconsola sea nuestra competencia, pero es que… por calidad y alcance TAMPOCO veo mucho más competencia local más allá de ¿juegosalmejorprecio.com? Y eso, me preocupa. Tiene que haber más competencia y quiero descrubrirla.

          • Alberto

            Es cierto que crítico no hay (casi) nada, *pero* no estoy de acuerdo.

            Me parece una feature que tiene mucho valor de cara a vuestro futuro. En serio. Es el primer paso que os hace ir un poco más allá de un simple listado de precios. Algo que es más fácilmente copiable. Aún sin ser perfecto, con el Otoscore tenéis un valor añadido respecto a vuestra competencia real que os da ventaja.

            Y que para cuando os copien (si copian), vosotros ya estaréis en otra cosa. Eso suponiendo que sepan para que les puede servir.

            En serio, en *mi opinión* lo que habéis hecho es *muy bueno* de cara a vuestro futuro, por mucho que fuera sin querer.

  • Javier López

    Sobre lo que comentáis de copiar a la competencia, lo que yo aconsejo siempre es hacer “competencia a la japonesa”. Es decir, copiar las mejores ideas de la competencia pero haciendo una iteración de mejora sobre ellas.

    Copiar es bueno. Copia y mejora. Pero si copias algo de la competencia intenta mejorarlo, imbuirlo de tu propio espíritu, añadirle tu visión, adaptarlo a tu planificación.

    La mentalidad japonesa es muy afín a esa idea. Y nunca me ha dado vergüenza admitir que muchas de las mejores ideas de @erasmusu son ideas mejoradas vistas en otras webs.

    Y sobre el PM… mi opinión es que un buen Product Manager no solo tendrá siempre en mente una planificación futura, sino que sabrá mantenerla orgánica para poder adaptarse rápidamente a cualquier contingencia. Eso incluye mantener vigilada a la competencia, estudiando qué cosas les funcionan y qué no y adaptando en consecuencia la planificación. Pero mucho más importante es tener claros los propios objetivos e hitos necesarios a desarrollar para llegar a dichos objetivos.

    Muchos parámetros 🙂

  • Jose Luis Vazquez

    Quizá un poco off-topic, o algo que ya saben todos por aquí, pero lo suelto por si acaso.
    Es algo más relacionado con el video de Henrik Kniberg que con “la maniobra Loco Ivan”.

    Se menciona la dificultad para poder estimar los costes de desarrollo con antelación, costes que en su mayor parte se miden en tiempo que los desarrolladores tardan en terminar sus tareas asignadas.

    Se trata del Evidence Based Scheduling de Joel Spolsky:
    http://www.joelonsoftware.com/items/2007/10/26.html
    Me imagino que es de dominio general, pues el artículo es relativamente viejo y hasta existe una entrada en la Wikipedia al respecto:
    http://en.wikipedia.org/wiki/Evidence-based_Scheduling

    Me pregunto que opinan los que lo conocen de hace tiempo,o si existe ya alguna otra tecnica o refinamiento más reciente.

    Por si acaso, resumo rápido la idea por si a alguien no le suena:

    1) Partir los desarrollos en tareas lo más pequeñas y manejables posibles, parecidas o asimilables a otras ya realizadas para poder predecir su duración. (Algo que ya menciona el video)

    2) Medir el tiempo real de cada tarea para cada persona y compararlo con la predicción.

    3) Con el paso del tiempo, las desviaciones típicas sirven para correjir bastante fiablemente las estimaciones a priori, incluso en entornos con interrupciones e imprevistos recurrentes.

    Por supuesto, todo esto es un peñazo hecho a mano, en especial tratándose de estimaciones de tiempo, que a los desarrolladores nos revientan. Conviene una herramienta para meter las tareas, las predicciones y marcar los inicios/finales de tarea para que la herramienta calcule desviaciones, etc.
    ¿ Conocéis buenas herramientas de esto? ¿las hay opensource?
    ¿Hay otras más nuevas y mejores (en su tecnica o refinamiento)?