Hemos llegado a la sesión 12 del programa de dirección de producto en el Instituto Tramontana. Una sesión donde nos apuntamos varios retos de la estrategia cuando trabaja con el material digital.

El cuarto movimiento de nuestra máquina de descubrimiento es cuando publicamos. En esta sesión también le dedicamos un rato a discutir varios aspectos interesantes de lo que se suele entender por "validación" en los productos digitales. Es una noción que conecta tanto con el momento de lanzamiento como con momentos anteriores. Nos apuntamos, como conclusión principal, que tomarlo prestado de otras disciplinas o industrias puede distorsionar su realidad más cercana a la contrastación que a la aportación de un sello.

Dirigiendo producto es difícil no rendirse ante el influjo de la palabra “estrategia”. Te puede hacer sentir una persona muy pequeña y al mismo tiempo no tener claro lo que significa. Te puede hacer dar pasos en la dirección equivocada con la mejor de las intenciones y al mismo tiempo prestarle poca atención a las cosas pequeñas. Finalmente, te puede llevar a querer abstraer tanto que acabes pretendiendo hacer un encadenamiento lógico, top-down, que luego se derrita al contacto de la realidad. Intencionadamente, la analizamos después de haber recorrido los otros momentos, porque de otra forma desatenderíamos las numerosas decisiones estratégicas que se producen a lo largo de la propia invención.

Si la oyes nombrar mucho, señal de peligro.

Antes de haber empezado a construir nada es bastante razonable intentar validar principalmente la información con la que trabajamos. En este sentido, adelantar los equipos de ingeniería tiene principalmente esta función de empezar a validar si lo que se está proyectando tiene encaje con lo que existe, así como para empezar a tener una noción de riesgo e incertidumbre en lo que se está planteando.

Durante la construcción, es recomendable establecer hitos de validación. El primer arranque de cualquier construcción suele ser una etapa de descubrimiento de todas aquellas cosas que no se podían saber antes de empezar a construir y que aparecen en el momento en el que se ponen en juego. Aquí ya tenemos una validación de las asunciones previas. Puede llevar a modificar sustancialmente el alcance. Intenta evitar la validación de soluciones proyectadas, porque precisamente suelen estropear mucho esa referencia del alcance.

Las falsas expectativas deterioran la confianza.

Pero también es recomendable establecer validaciones progresivas de la solución que se está construyendo, de forma que se empiece a interactuar lo antes posible con ella. Lo ideal es hacerlo tanto dentro del equipo que la construye como incorporando a personas ajenas a él, para que también haya una cierta validación que al menos permita evitar los desencajes mayores al lanzar. Cuando no construyes en equipo desde el día 1, es muy probable que acabes en la trampa de extender el tiempo, o que acabes construyendo algo a medias, porque no te has dado esos momentos de decisión, a lo largo del proceso, donde puedes ir ajustando el alcance alrededor de lo que consideras el epicentro.

Mejor la mitad de un producto que no un producto a medias.

La validación después de lanzar viene determinada, en buena medida, a partir de la clasificación que le hayamos dado a la solución. Es decir, si recordamos sesiones anteriores, nos dábamos tres tipos de iniciativas: problemas de clientes, palanca de métrica, deleite. La validación varía sustancialmente en función de esta clasificación. En el primer caso, podemos buscarla a través de una interacción inmediata con los clientes, o combinando resultados cualitativos con cuantitativos. En el segundo caso, una observación cuantitativa del comportamiento de ciertas métricas debería valernos. En el tercero, hay muchas posibilidades y no es raro que a menudo se trate simplemente de un criterio interno: la directora de marketing y el CEO lo ven bien.

Fomentamos la paciencia y el buen humor como ingredientes clave de la gestión de producto digital.

Los lanzamientos también se pueden dar de distintas formas. En esto también lo digital te da una plasticidad que, de nuevo, te enfrenta a múltiples opciones. La diferenciación principal suele ir de lanzamientos de una vez, totales, frente a lanzamientos progresivos. También esta se utiliza como una forma de validación. Por ejemplo, las plataformas de desarrollo móvil han establecido como un estándar el que las lances a partir de porcentajes, y los equipos de ingeniería suelen funcionar, a partir de esto, con la idea de que les permite ir validando si aparecen problemas.

Pero también puedes utilizar el lanzamiento interno frente al lanzamiento externo. Si estás trabajando en un producto que se utiliza internamente, es habitual que las funcionalidades estén un tiempo antes dentro de la empresa, y que salgan afuera cuando ya se han validado e incluso se han refinado. Tienes que apuntarte, en cualquier caso, que todas estas posibilidades incrementan la complejidad, empezando por su instrumentalización y siguiendo porque ellas mismas añaden incertidumbre y problemas de coordinación.

La falta de confianza suele decidir mucho la cultura de rollout.

Los lugares comunes a los que ha llegado la literatura sobre estrategia nos aportan puntos interesantes para situarla en nuestro contexto de los productos digitales. Es una literatura que a menudo se ha ido formando a partir de ejemplos de lo que no se considera estrategia. La primera referencia que, por ejemplo, Michel Porter utilizaba para enmarcar la cuestión de la estrategia, solían ser las compañías que buscaban la eficiencia operativa.

Si estás mirando mucho a tus competidores, no estás fomentando tu estrategia.

La estrategia, por lo tanto, se tiene que traducir en un conjunto de acciones específicas (por diferenciales), y estas acciones tienen que ser el resultado de un proceso de descubrimiento y creatividad. Cuando una empresa pose en juego su estrategia, está poniendo en juego su posicionamiento, que se suele articular en función de a quién se dirige (target) y qué ventaja competitiva (advantage) pone en juego. De la combinación de esos factores es de donde se suelen extraer los distintos modelos de estrategia, así como el modelo que se considera la "no estrategia". Es, además, la situación habitual.

Si la estrategia es la creación de un posicionamiento único que implica un conjunto característico de actividades, hacer que esa ventaja sea sostenible tiene mucho que ver con sacrificar. La selección de trade-offs es, por lo tanto, el ejercicio principal donde se realiza la estrategia.

La plasticidad y versatilidad de los productos digital solo empeora nuestra mala relación con los sacrificios.

Hay numerosas razones que explican la ausencia habitual de estrategia. Y son en su mayoría internas, es decir, las organizaciones son su propio problema. En primer lugar, muchas compañías se limitan a imitar a otras: los hábitos orientados a la escucha activa y al descubrimiento, que vimos en sesiones anteriores, son un buen jarabe para una enfermedad tan persistente. Asimismo, el deseo de crecer suele subordinar a todo el resto, especialmente cuando estás en un momento dominado por el PLG. La falta de visión en el posicionamiento de los competidores y los fallos en la organización que obstaculizan articular un posicionamiento, también son causas habituales de la falta de estrategia. Finalmente, la incapacidad para hacer sacrificios, muy habitual en culturas de management donde esto se ve como una debilidad y no como una fortaleza, se hace especialmente grave en el terreno digital, donde se amplían las opciones, se entiende poco del material y se aumenta la percepción de una falsa abundancia.

Managers que no sacrifican no pueden ser estratégicos.

Terminamos haciendo un recorrido por la caja de herramientas de los roadmaps como instrumentos para hacer tangible y operativa una estrategia. Tomamos como referencia el modelo DHM (delight, hard to copy, margin), porque combina de forma muy razonable narrativa (visión), planificación y estrategia.

Evita, además, caer en los habituales roadmaps, en forma de línea de tiempo de gestión de proyectos, donde las empresas naufragan estrepitosamente. Le dedicamos un buen rato a ver este gran desperdicio en el que nada nuestra industria, y donde tantos CEOs hacen que los equipos pierdan la creatividad y la moral. Una vez más: los problemas con los que trabajamos no son piezas técnicas de lego, que puedes descomponer en una secuencia temporal de cajas, convirtiendo así el roadmap en una herramienta exclusiva de status. Haciendo esto no solo vas a fracasar en la ejecución -no se cumplirán los tiempos porque la naturaleza del software irá en tu contra-, sino que además te vas a privar de la parte más interesante: convertir esa pieza técnica en una historia.

Si lo combinas con una implantación apresurada de OKRs, es querer tener éxito hundiendo el barco.

El roadmap no debe ser la foto fija.

¿Es acaso la estrategia en el producto digital algo tan escurridizo que estamos condenados a malvivirla?