Retos de la estrategia en producto digital

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 se 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 tomarla prestada 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, simultáneamente, prestarle poca atención a las cosas pequeñas. Finalmente, te puede llevar a querer abstraer tanto que acabes pretendiendo un encadenamiento lógico, top-down, que luego se derrita al contacto con 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. Esa es una de las asimetrías más incómodas del oficio: la estrategia se escribe en documentos y se decide en detalles. Si la oyes nombrar mucho, señal de peligro.

Validaciones antes y mientras construimos

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 sobre todo esta función: empezar a validar si lo que se está proyectando tiene encaje con lo que ya existe, así como empezar a tener una noción de riesgo e incertidumbre en lo que se plantea.

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 y que solo aparecen en el momento en el que se ponen en juego. Ahí ya tenemos una validación de las asunciones previas, y puede llevar a modificar sustancialmente el alcance. Intenta evitar la validación de soluciones proyectadas, porque precisamente suelen estropear mucho esa referencia del alcance: cuando enseñas una solución cerrada, la conversación deja de ser sobre el problema. Las falsas expectativas deterioran la confianza.

«¿El email no llega? Puedes probar todo en Figma.»

Pero también es recomendable establecer validaciones progresivas de la solución que se está construyendo, de forma que se empiece a interactuar con ella lo antes posible. Lo ideal es hacerlo tanto dentro del equipo que la construye como incorporando a personas ajenas a él, para que 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.

Es el mismo principio que trabajamos en la sesión anterior sobre cómo evitar el desperdicio y favorecer el ritmo: el alcance no es un punto de partida, es algo que se desenvuelve. La validación intermedia es lo que te da los puntos de apoyo para desenvolverlo con criterio en lugar de por agotamiento.

La validación después de lanzar viene determinada, en buena medida, por la clasificación que le hayamos dado a la solución. 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 esa 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, 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.

Conviene decirlo sin rodeos, porque la confusión aquí es habitual y costosa: pedirle a una iniciativa de deleite que demuestre movimiento en una métrica de negocio, o pedirle a una palanca de métrica que demuestre entusiasmo cualitativo, es una forma bastante eficaz de tomar decisiones equivocadas con la sensación de estar siendo rigurosos. Fomentamos la paciencia y el buen humor como ingredientes clave de la gestión de producto digital.

Paciencia y buen humor, en la sesión 12.

## Lanzamientos totales frente a lanzamientos progresivos

Los lanzamientos también se pueden dar de distintas formas. En esto 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 estándar que lances a partir de porcentajes, y los equipos de ingeniería suelen funcionar con la idea de que eso 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 refinado.

Tienes que apuntarte, en cualquier caso, que todas estas posibilidades incrementan la complejidad. Empezando por su instrumentalización —alguien tiene que construir y mantener el sistema de flags, cohortes y medición— y siguiendo porque ellas mismas añaden incertidumbre y problemas de coordinación. Un producto lanzado a tres velocidades distintas es, durante un tiempo, tres productos distintos: soporte responde a tres realidades, la analítica mide tres poblaciones y el equipo mantiene tres caminos de código. La falta de confianza suele decidir mucho la cultura de rollout, y merece la pena preguntarse si el mecanismo progresivo está resolviendo un riesgo real o administrando un miedo.

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

## La estrategia va más del NO que del SÍ

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, Michael Porter utilizaba para enmarcar la cuestión eran las compañías que buscaban la eficiencia operativa. Hacer lo mismo que los demás algo mejor no es una estrategia: es una carrera de convergencia en la que todos acaban ofreciendo lo mismo y compitiendo solo en precio.

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 —específicas porque son diferenciales—, y estas acciones tienen que ser el resultado de un proceso de descubrimiento y creatividad. Cuando una empresa pone 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. Y aquí es donde el material digital nos juega en contra: la plasticidad y la versatilidad de los productos digitales solo empeoran nuestra mala relación con los sacrificios. Cuando todo parece posible, renunciar parece un error de gestión y no una decisión.

La plasticidad de los productos digitales 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 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.

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.

Merece la pena detenerse en una confusión que sostiene buena parte de este problema: la que hay entre objetivos y estrategia. Un objetivo describe un estado que quieres alcanzar; una estrategia describe cómo vas a tratar la dificultad que te separa de él. Cuando una organización enuncia "queremos duplicar la retención" y lo llama estrategia, en realidad ha saltado por encima del único trabajo que importaba: identificar qué obstáculo concreto está produciendo el abandono y qué conjunto coherente de acciones lo aborda. Ese salto es cómodo porque un objetivo no exige renunciar a nada.

Roadmaps para articular la estrategia

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, planificación y estrategia. Su virtud es que fuerza a responder tres preguntas que normalmente se contestan por separado, y a menudo por departamentos distintos: qué hace que esto entusiasme a alguien, qué hace que no se pueda copiar en un trimestre, y por qué esto deja dinero. Una iniciativa que solo puntúa en la primera es marketing; una que solo puntúa en la tercera es extracción.

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 puedas 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. Los OKRs solo funcionan cuando existe algo previo que enmarcar; aplicados sobre una organización sin posicionamiento, lo único que hacen es acelerar y dar apariencia de rigor a la dispersión que ya había.

El roadmap no debe ser la foto fija.

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