Artículo escrito por Íñigo Medina, director del programa de Dirección y Cultura de Producto.
Hacer bien producto digital pasa por entender la propia naturaleza del software. A pesar de ser su principal material, la mayoría de las veces es ignorado, cuando no malinterpretado. El software no es madera, ni su tratamiento es el que históricamente hemos llegado a elaborar en torno a la arquitectura y otras disciplinas con los que operamos en el mundo no digital. Parece que muchas veces es lo que nos gustaría que sucediera, pero la realidad es tozuda y siempre nos acaba haciendo ver que ese marco no encaja.
Las empresas cuyo negocio es el propio producto digital suelen adolecer de esa mala comprensión del software y con demasiada frecuencia parecen luchar en contra de su naturaleza. A partir de ahí muchas expectativas están mal orientadas, produciendo organizaciones menos productivas y profesionales de lo que podrían ser.
La experiencia empírica diaria es el mejor antídoto para no caer en esa mala comprensión. Vamos a recorrer algunos ejemplos que creo que le resultaran patentes a cualquier persona un poco familiarizada con esta industria.
Una entrada, muchas salidas
El software desvanece nuestras aspiraciones de control integral sobre el resultado final.
Nuestro cerebro todavía no asimila bien que algo que proyectamos no se materialice de forma prácticamente idéntica al modelo. Las compañías que inventan productos digitales se enfrentan constantemente a este reto y el anecdotario de situaciones divertidas, a pesar del fondo dramático sobre el que muchas veces tienen lugar, es realmente abundante y rico: diseños que persiguen un color exacto y que acaban teniendo distintas modulaciones en función del monitor y la configuración; disposiciones visuales que persiguen un determinado efecto y que acaban teniendo un resultado distinto o simplemente aparecen rotas en función de una determinada resolución, un cierto tipo de dispositivo, o una versión de cierto programa dentro de cierto tipo de dispositivo; flujos de interacción, que involucran datos y comunicaciones, que nunca llegan a sus destinatarios bien porque dependen de algo que estos deben activar, bien porque dadas ciertas condiciones de ambiente -red, localización, momento del día- no tienen lugar; experiencias diseñadas, donde puede llegar a intervenir la imagen, el movimiento y el sonido, que no tienen el desenlace esperado o lo tienen solo parcialmente, porque algo no va bien en el sistema, es decir, en el conjunto de todas las condiciones que tienen que darse.
El cerebro entrenado en bellas cadenas de montaje donde el encaje de elementos en la entrada acaba dando la salida prevista -desde un automóvil a una hamburguesa- vive aquí su primera crisis. Y las personas no pueden dejar de tener que responder a ese colapso: a veces sencillamente se fugan -la realidad está mal o todavía no está lo suficientemente bien- y otras arrastran la carga de malvivir con algo que siempre produce insatisfacción.
Cajas negras
Lo que no ves del software es más que lo que ves.
Los productos digitales nos acercan a lo que solemos vivir con nuestro propio cuerpo: pasan cosas dentro que no podemos entender atendiendo exclusivamente a nuestra epidermis. ¿Acaso no sucede que una analítica clínica -métricas de producto- te da valores correctos pero cuando te operan -te abren- descubren algo distinto a partir de una información que se ha hecho visible?
Esta naturaleza de caja negra es algo que puedes experimentar con frecuencia. Por ejemplo, los errores en los productos digitales están totalmente normalizados. También, el hecho de no poder explicar satisfactoriamente por qué suceden. En ocasiones se alcanzan explicaciones superficiales, pero es muy común abandonar la aspiración de dar con la causa raíz, porque el esfuerzo no merecería la pena, pero también porque sobrevuela la sospecha de algo multifactorial que ni siquiera se podría rastrear correctamente en un sistema opaco.
Inventar con software es aceptar que lo inesperado es algo corriente.
Información dinámica
Trabajar con software es aceptar que trabajas con piezas cambiantes.
La información en los productos digitales es inherentemente dinámica. A diferencia de otro tipo de productos, donde la información suele ser estática una vez impresa o grabada, en el software los datos y las estructuras están en constante flujo. Empezar a desarrollar suele ser también el momento de descubrir que algo no estaba como pensabas; que algo cambió en algún momento sin que lo tuvieras en cuenta; o que algo directamente dejó de funcionar.
Los equipos experimentan a diario este fenómeno, pero también los clientes, sin que muchas veces resulte fácil determinar qué capa, de las muchas que intervienen, es la que lo ha causado.
Ramificaciones
El aleteo del software puede tener consecuencias imprevistas.
Las ramificaciones son otro aspecto singular del software que suele sorprender a quienes no están familiarizados con su naturaleza. Un cambio aparentemente simple puede desencadenar un racimo de efectos inesperados en otras partes del sistema. Esto se debe a la compleja interconexión de los componentes y a la naturaleza dinámica de la información que maneja el software.
A veces el aleteo tiene consecuencias descomunales como en el caso reciente de Microsoft y CrowdStrike.
En la práctica tiene tanto peso, en muchas ocasiones psicológico, que las expresiones habituales cuando se está incorporando algo nuevo al producto son de estilo cauteloso en la forma de "en principio no debería afectar". La proliferación de métodos para hacer despliegues progresivos -por porcentajes, cohortes, o directamente por feature flag- es otra buena confirmación de lo interiorizado que está este fenómeno, puesto que el foco no está en cómo conseguir que no suceda sino en desplegar una red de seguridad puesto que se sabe que va a suceder en algún grado.
Plasticidad
Trabajar con software tiende a ser un proceso creativo sin contornos establecidos.
Cuando el único límite es tu imaginación, es fácil que la exuberancia te confunda. Los productos digitales contienen una cierta promesa de economía de la abundancia que tiende a despreciar lo que la economía tradicional, una economía de la escasez, ponía en valor. Sabemos que este tipo de productos no suspende las lógicas que ya conocíamos, así que posiblemente se trata más de un problema de percepción que de cambio real.
La maleabilidad del software sí es un hecho, para empezar por su propio propósito general. Esta plasticidad es algo que puedes comprobar a menudo, especialmente cuando se plantea una funcionalidad con un enfoque de reunir el conjunto integral de sus piezas para llevarlas a ejecución, y las propias piezas se van convirtiendo en nuevas posibilidades que engendran otras, y estas otras, y estas otras, en una secuencia abierta. En la industria es habitual utilizar expresiones del tipo "diseñar a máximos" para referirse a este tipo de situaciones.
Un poco de historia
La historia del software es joven. Más aún la del producto digital orientado a internet. Aun así, ofrece algunas referencias relevantes que nos ayudan a ver que efectivamente esa naturaleza singular del software fue detectada desde los mismos inicios, y que se vienen formulando distintas aproximaciones para ver cómo gestionarla.
En primer lugar, sabemos que desde los años 30 del siglo XX se empiezan a formular planteamientos que se denominan Iterative and Incremental Development. Nacen de algunos ingenieros dedicados a la calidad, que empiezan a mostrar preocupación por algunas situaciones y proponen distintas soluciones. Ya en los años 50 y 60 se están aplicando este tipo de enfoques iterativos e incrementales en proyectos en organizaciones tan significativas como la NASA e IBM.
También sabemos que hacia los 70 ya se había consolidado el debate entre este tipo de metodologías y aquellas que acababan agrupadas bajo la etiqueta de "desarrollos en cascada", que se consideraban la forma estándar, puesto que importaban estilos de gestión que ya se conocían anteriormente y que se habían popularizado con la revolución de las organizaciones industriales y la gestión de proyectos.
Artículo de Royce exponiendo y señalando las limitaciones del método en cascada a partir de sus propias experiencias.
Los objetivos en la gestión solían relacionarse con cumplir plazos y costes, y en muchos aspectos sigue siendo una perspectiva dominante aún hoy. Las compañías también suelen tener una predisposición para promocionar el pase de testigos como si se trataran de cadenas de montaje que en vez de unir planchas y tuercas, unen piezas de software.
A medida que se fueron consolidando este tipo de enfoques, fue cogiendo peso la línea que buscaba nuevas formas de programar y de organizar a los equipos en torno a la programación. En los años 90 se empiezan a publicar introducciones a la corriente conocida como extreme programming. Es el momento en el que el terreno de la programación ya empieza a mezclarse con un vocabulario que hasta entonces había permanecido en los márgenes, o directamente no había existido: la evaluación del éxito ya no venía por el cumplimiento de tiempos y costes sino por la propia satisfacción de los clientes.
Finalmente, ya hacia la década que inaugura el año 2000 se publica el famoso Manifesto for Agile Software Development, con la firma de relevantes programadores. Sabemos, por lo tanto, que los distintos enfoques y formas de trabajar con el software nacían de las mismas personas que mejor lo conocían. En este momento, los tiempos y los costes han desaparecido ya por completo como principales objetivos, y en su lugar cogen protagonismo, entre otros, la colaboración con los clientes y la capacidad para responder al cambio.
En apenas 70 años la mirada sobre el desarrollo de software ha cambiado drásticamente.
Hoy ya manejamos como moneda común, especialmente cuando nos centramos en tácticas alrededor del desarrollo de productos digitales, cosas como los desarrollos atómicos, las técnicas de slicing, la entrega continua, las implementaciones iterativas, los despliegues progresivos y, en general, una caja de herramientas que se mantiene viva a través de aportaciones constantes.
Clientes borrosos y problemas complejos
Ese giro hacia los clientes, incluso situándolos en un plano de colaboradores, añadió una nueva capa de complejidad a esa otra del software en la que nos hemos centrado hasta ahora. En primer lugar, porque se sumaba otra incógnita: ¿cómo llegar a saber quiénes son esos clientes? Cuanto más capacidad y relevancia han ido ganando los productos digitales, mayor número de usuarios y clientes los utilizan. Actualmente, puedes decir sin miedo a exagerar que la magnitud de algunos productos tiene el mismo impacto que realidades no digitales tan relevantes como, por ejemplo, la organización del tráfico.
Actividades como el user research fueron surgiendo como una forma de ir despejando esa incógnita, al mismo tiempo que se incorporaba capacidad analítica para cuantificar comportamientos a través de interacciones. A través de un conjunto de atributos -clicks, visitas, funnels, sesiones, etc.-, conversaciones, encuestas, ejercicios de user testing y otras técnicas de una caja de herramientas que se ha enriquecido a lo largo de los años, intentamos satisfacer esa aspiración tan repetida de poner a las personas en el centro, y de ponerlas con cierta certeza de que no son directamente una invención nuestra. No es raro que muchas veces todo termine en una ilusión: las compañías haciendo de ventrílocuos, poniendo sus demandas en boca de esos clientes desconocidos.
Además, con la apertura a los clientes vino una reformulación de los problemas, que fueron pasando de considerarse proyectos consistentes en un conjunto de requisitos y una secuencia de tareas, a enfrentarse a lo que los científicos sociales suelen denominar problemas complejos, pero que también desde la perspectiva del design thinking se ha verbalizado como problemas perversos, retorcidos o también débilmente definidos (wicked problems). Un tipo de desafíos que carecen de soluciones o límites claros; que no tienen una respuesta definitiva ni suelen darse en una formulación clásica, y sus posibles soluciones no son enumerables.
Artículo de Buchanan donde reflexiona sobre la importancia de lo problemas débilmente definidos en design thinking.
Después de todo, este es el terreno en el que se mueven muchas de las cosas que intentamos resolver, y en el que tanto participan las ciencias sociales (¿cómo podemos resolver el envejecimiento de la población? ¿cómo podemos reducir el fracaso escolar? ¿cómo podemos reducir el impacto medioambiental?). Aunque en los productos las preguntas suelen ser más modestas (¿cómo podemos conseguir que los clientes mantengan más tiempo la suscripción? ¿cómo podríamos dar una mejor experiencia?), comparten esa naturaleza de pregunta abierta: tanto porque no siempre se está de acuerdo en que haya realmente un problema -es difícil que haya un hecho tan obvio que genere un consenso total- como porque nunca se aspira a eliminarla por completo, sino a moverse con indicadores relativos (un buen progreso es conseguir un 5% más de clientes que renuevan su suscripción).
Así que pasado ya el siglo XX los productos digitales no solo han afrontado numerosos retos relacionados con lo que era su material principal, el software, sino que además han incorporado, en su consolidación como parte relevante de la actividad económica, otros retos que los acercan a otras muchas actividades humanas en las que nos orientamos a través de conjeturas, arañamos un poco de hechos patentes para sacar consecuencias y nos las vemos con el riesgo y la incertidumbre. Algunas nuevas metodologías, como la de Jobs To Be Done, quieren ser una forma de reducir esos nuevos desafíos, incorporando contexto real y situaciones concretas como una forma de minimizar esa indefinición de límites.
Es fácil ver que el producto digital se ha hecho adulto, aunque con frecuencia las organizaciones que los inventan no sigan el mismo ritmo de madurez y lo sigan tratando como a aquel crío que era meramente un recurso técnico. Hay mucho margen de mejora en organizaciones que cuidan la cuenta de resultados o el modelo de negocio, pero que tratan el producto, que es la fuente de esas finanzas, o bien a través de peticiones o bien a través de grandes corazonadas volcadas en un backlog.
Una incidencia de contorno estrecho no puede gestionarse igual que una decisión estratégica, como tampoco se trata igual el arreglo de un asiento en un tren y el rediseño de la propia red ferroviaria. En muchas compañías los asientos y las redes ferroviarias se confunden, y se tiende a intentar resolver ambos de la misma forma: todo se valora únicamente como cantidad de trabajo hecho sin buscar la correlación con unos resultados esperados.
Organizaciones más productivas y profesionales
Cuanto más fuerte es la relación de una compañía con la invención de producto digital, o lo que viene a ser lo mismo, cuanto más es su negocio el propio producto, más se ve afectada por estos aspectos que acabamos de recorrer. Cuando no incorpora esta reflexión, a menudo malvive porque trabaja en un marco incorrecto. Por lo tanto, ni se da, como organización, la forma adecuada de pensarse, ni ofrece a las personas que la conforman el entorno en el que podrían ser más productivas.
En primer lugar, a este tipo de compañías les sienta mal inventar a partir de proyecciones de alta fidelidad. Si el Figma es el punto de partida y además alguien lo valida, ya sea el CEO -algo todavía más común de lo que suele pensarse- o cualquier otra figura directiva, es muy alto el peligro de deslizarse por la pendiente de desarrollos que parecen no tener fin. Igualmente, el riesgo de tener poca velocidad (a veces la discusión queda secuestrada en el propio Figma). Asimismo, tendrá que apuntarse en el debe mucha frustración y pérdida de talento en sus equipos, puesto que ese resultado final, proyección de ese diseño a máximos en alta fidelidad, nunca podrá alcanzarse tal como se imagina, porque como hemos visto no existe esa correspondencia unívoca entre entrada y salida.
Los productos digitales tratados como cadena de montaje suelen acabar siendo engendros.
Son compañías, por lo tanto, a las que les sienta bien el punto gordo -baja fidelidad- y tocar para entender. O también, validar para reducir riesgo. Necesitan fomentar el ir a lo real para poder formarse una opinión. No es raro, en consecuencia, que les favorezca un estilo donde predomina el hacer cosas y compartirlas lo antes posible para ver qué tal son recibidas; el involucrar a los potenciales usuarios y clientes en el propio proceso de invención para incorporar aprendizaje lo más pronto posible; así como el insistir en que el ritmo, en sí mismo, es un valor positivo (el mantra speed wins es posiblemente el que mejor sintetiza esa orientación).
Tocar para entender también significa que son organizaciones que malviven cuando no tienen interiorizado este material con el que trabajan: el negocio que puedes imaginar también está en función de tu comprensión de, por ejemplo, cómo funciona una petición en un navegador.
Release early, release often.
Pero también, en esta misma línea, son organizaciones a las que les favorece hacer una reflexión sobre cómo quieren organizarse para inventar, puesto que no pueden tomar prestados estilos que han funcionado en otras industrias en el pasado y asumir que son una plantilla operativa con independencia del material con el que trabajan. A este respecto, les sienta mal todo lo que lleva a pensarse en términos de organización meramente ejecutiva: estimaciones de horas, estimaciones de costes de los requisitos, estimaciones del número de personas que se podrían sumar para acelerar las ejecuciones, etc.
Les sienta bien fijarse en organizaciones asociadas a la creatividad colectiva -desde la industria del entretenimiento hasta el deporte-, donde una persona no es un recurso -importa el quién y no solo si es backend o frontend- y donde la propia organización tiene que incorporar una reflexión constante y cambiante sobre cómo se articula -la forma en la que se organiza un rodaje de una película o se piensa la táctica de un deporte colectivo tienen muchas similitudes con los retos que enfrentan este tipo de organizaciones.
Los productos basados en software se llevan mejor con las mentes colmena.
No es, por lo tanto, extraño que este tipo de compañías vivan en un rumor constante sobre la última metodología de moda que parece que por fin podría aportarles ese sentido para manejar las situaciones que nunca llegan a encajarles. Las compañías que sí han entendido que parte de su funcionamiento incluye el inventarse cómo inventan, son las que van poniendo novedades en ese mercado de las metodologías, ya sea Spotify, Duolingo o Basecamp.
Lo más prudente sería imitarlas en la vocación y no en el resultado, aunque suele darse más lo segundo, y por ahí se suele coger, por así decirlo, la piel muerta de la serpiente: lo que le sienta bien a Google, no le tiene por qué sentar bien a tu organización. Menos aún si tu compañía no tiene ninguna similitud ni de tamaño, ni de negocio, ni de personas ni, en general, de cultura.
Los equipos de producto digital no pueden dejar de pensar cómo se organizan.
Asimismo, son compañías a las que les sienta mal ser ágrafas, a pesar de que en muchas ocasiones funcionan en modo oral. La toma de decisiones en un entorno tan resbaladizo, en el sentido de no poder contar con un suelo razonablemente firme de hechos obvios sobre los que montar conjeturas, agradece un apoyo deliberativo escrito. Es el espacio donde se puede articular la mucha o poca evidencia que se tenga sobre algo -en forma cuantitativa o cualitativa-; donde se pueden explicitar las conexiones lógicas, fuertes o débiles, que están detrás de una decisión -para que el propio juego de la escasez y los usos alternativos del dinero tengan algo en lo que apoyarse-; y donde se pueden armar las historias que motivan esas decisiones.
También es la forma de cohesionar la organización y articular su propia estrategia, que nunca puede ser simplemente el volcado de unas tareas en un backlog. Menos aún si los posibles argumentos que conectan esas tareas se han despachado oralmente.
Es necesario racionalizar el proceso que lleva de capturar una posible oportunidad, a moldearla a partir de posibles soluciones a, finalmente, construir algo.
En esa función de compensar incertidumbre y riesgos, son compañías que también necesitan dotarse de una disposición específica hacia las métricas y el uso de lo cuantitativo. Nuestras intuiciones mejoran cuando las contrastamos con patrones estadísticos, y también cuando nos habituamos a la búsqueda de guías cuantitativas. A este tipo de compañías les sienta bien contar con personas que piensan en términos de magnitudes antes que en la exactitud de los tres decimales.
Es el camino a través del cual se puede conseguir cuantificar la incertidumbre, y desde ahí construir conjeturas probables. Es natural que resuenen distintos estilos de articular estas compañías en torno a métricas -desde OKRs hasta north stars declinados en indicadores-, puesto que las métricas les ayudan a reducir el riesgo de las apuestas que hacen.
Las métricas son una brújula que no prescribe el camino para llegar al destino.
Al tratarse de organizaciones que, por el propio material con el que trabajan, deben dar importancia tanto a la consecución de objetivos como al incremento del aprendizaje, necesitan también afrontar el reto de actuar como una inteligencia colectiva. Fomentar la autonomía de los equipos, sin subordinarlos a procesos de validación directivos, se convierte en una necesidad desde el momento en el que solo las personas que están trabajando con el material disponen de la información adecuada y actualizada para tomar decisiones.
Es natural que proliferen metodologías que reman a favor de organizaciones con directivas ocupadas exclusivamente en armar las temáticas troncales mientras delegan no solo la ejecución sino también en muchas ocasiones las mismas decisiones (las numerosas que se producen en el mismo proceso de crear) de qué hacer para realizar esas temáticas troncales.
Son compañías, por lo tanto, a las que les sienta bien involucrar cuanto antes a cualquier persona que tenga conocimiento valioso y contrastado, y no simplemente dejarles una pequeña parcela de ejecución: la persona que programa es tan valiosa cuando programa como cuando no lo hace, por ejemplo, porque está diseñando distintas soluciones para un problema o porque está indagando en las restricciones que pueden condicionar esas soluciones, o porque está experimentando con algo nuevo que también podría acabar resultando la llave para resolver algo de forma inesperada.
El tiempo y la atención son dos factores relevantes en el desarrollo de productos digitales.
Finalmente, este tipo de organizaciones tiene la necesidad de poner a sus clientes en el centro, porque son una fuente relevante de información y aprendizaje: ayudan a desvelar ramificaciones y aspectos ocultos de la caja negra; su propio uso aporta luz con la generación de errores y de experiencias donde la salida no se corresponde con lo que se proyectaba en la entrada, pero también permitiendo articular decisiones basadas en algunas regularidades cuantitativas y ayudando a dar perímetro a funcionalidades que de otra forma podrían acabar siendo un agujero de gusano, comprometiendo la propia viabilidad de la empresa. En este sentido, a diferencia del estilo de otro tipo de compañías del pasado, a estas les sienta bien derribar el muro que separa su interior del exterior.
Las compañías tienen tendencia a crear muros entre las personas que inventan y las personas para las que inventan.
Es natural que se hagan populares lemas como dogfooding, donde organización y cliente se confunden al utilizar la primera su propio producto para poder tener la experiencia del segundo. La calidad pasa a ser, de alguna forma, un control colaborativo. Toda la corriente, que hemos mencionado anteriormente, sobre el conocimiento del contexto y la conversación directa con las personas necesita ser incorporada de alguna forma. Estar al otro lado del espejo es tan troncal para este tipo de compañías que incluso para las mismas incidencias diarias las capturas y grabaciones de pantalla, los datos de la situación para poder reproducirla, la capacidad para entrar en la cuenta del cliente para poder ver lo mismo que ve, son situaciones totalmente naturalizadas.
La forma más efectiva de entender a alguien es vivir un poco su vida.
Al contrario de lo que suele pensarse, fomentar la escasez les aporta muchos beneficios a este tipo de organizaciones. Precisamente porque sirve de contrapeso a la abundancia (de anomalías, posibilidades y materializaciones) que caracteriza al software. A estas compañías les sienta bien moverse en un marco de decisiones en forma de apuesta y apetito. Es un marco que, además, resulta fácil de entender para cualquier persona, puesto que el hambre que tenemos por algo y lo que estamos dispuestos a sacrificar por eso se correlacionan de forma natural.
Las organizaciones mejoran cuando cambian la pregunta de cuánto me llevará algo -puesto que me obliga a hacer una estimación débil sobre un terreno incierto- a cuánto le dedicaría. Ya sea atención, dinero, esfuerzo o tiempo, que al final son todas caras de un mismo polígono.
El apetito nos ayuda a establecer lo central y lo periférico.
Lo digital no solo no ha invalidado la consigna tan repetida en economía de "nada es gratis", sino que nos empuja a recordárnosla más que nunca, para que trabajemos de forma más responsable y profesional. La ética es la primera beneficiada cuando las personas que hacen las compañías mejoran su conocimiento del material con el que trabajan. Justamente, por toda esta dificultad que acompaña a los productos basados en software.
