Crecimiento de productos tecnológicos

Posts from the ‘desarrollo de producto’ category

El vibe coding podría convertirse en la mayor amenaza para la actividad de descubrimiento de problemas en product management, pero los mejores equipos de producto transformarán la IA en un motor de descubrimiento en lugar de una fábrica de características.

Como vimos, una consecuencia indeseada del vibe coding es la facilidad con la que seduce a los equipos de producto para que pasen por alto el espacio del problema. La IA crea algo muy potente: la fuerza gravitatoria de la solución.

El vibe coding crea un campo gravitatorio alrededor de la solución

La gestión de productos de software abarca fundamentalmente dos ámbitos distintos:

  • El espacio del problema: El entorno donde residen los puntos de dolor del cliente, las necesidades del mercado, la fricción operativa y los incentivos económicos. Es un ámbito caótico, ambiguo, humano y difícil de cuantificar.
  • El espacio de la solución: El entorno donde residen las funcionalidades, las características y la experiencia de usuario. En productos software es el dominio de la arquitectura, los patrones de UX y el código. Es un ámbito estructurado, predecible, controlable y gratificante.

Por qué nos enamoramos del espacio de la solución

La psicología humana anhela una resolución. Pero descifrar un problema complejo del cliente exige lidiar con la ambigüedad, participar en entrevistas de descubrimiento incómodas y gestionar prioridades empresariales contrapuestas. El vibe coding ofrece una recompensa instantánea. Le das una instrucción a la IA: «Crea un panel de control para que los gerentes de cadena de suministro monitoricen los retrasos en el inventario». Treinta segundos después, aparece una interfaz elegante con gráficos, métricas y filtros.

Vibe coding y product managementLuego, la IA te invita naturalmente a profundizar más: «¿Quieres añadir alertas automáticas por correo electrónico? ¿Qué tal un sistema de previsión de la demanda basado en IA?». De repente, el gestor de producto pasa tres días perfeccionando el código, ajustando temas visuales y configurando gráficos sintéticos. El cliente, mientras tanto, ha abandonado la escena discretamente.

Requisitos frente a especificaciones: una distinción olvidada

Esta dinámica agrava un problema crónico en el desarrollo de producto: confundir los requisitos con las especificaciones.

  • Los requisitos definen quién tiene el problema, qué fricción experimenta y por qué resolverlo genera valor económico o estratégico.
  • Las especificaciones definen cómo nuestro producto resolverá el problema: funcionalidades, características, prestaciones.

Cuando los gestores de producto pasan directamente al vibe coding, escriben especificaciones disfrazadas de prototipos. Se saltan la definición del problema porque la herramienta hace que construir la solución sea extremadamente sencillo. Sin embargo, un desarrollador junior (ya sea un ingeniero humano o un modelo de lenguaje) no puede crear un producto exitoso sin comprender las dinámicas subyacentes del mercado.

Si nuestra comprensión del problema fundamental del cliente es errónea, el vibe coding solo nos permite construir lo incorrecto en tiempo récord. Hablamos de AI slop en el ámbito de los contenidos; esto es lo que esa «basura de IA» significa para el desarrollo de productos.

El dilema entre el espacio del problema y el espacio de la solución

La gestión de productos tradicional distingue dos elementos: el descubrimiento del problema (comprender las necesidades de los usuarios, la dinámica del mercado y los puntos de fricción) y el descubrimiento de la solución (comprobar si el enfoque propuesto satisface dichas necesidades). El error fundamental que propicia la creación de prototipos de IA es tratar cada prototipo como una solución que debe validarse, en lugar de como una herramienta para explorar cómo se realiza el trabajo en la realidad.

Cuando desarrollar es rápido y económico, surge la tentación de realizar más demostraciones de soluciones en lugar de profundizar en el descubrimiento del problema. Los equipos caen en un ciclo impulsado por las reacciones a las demostraciones: presentan prototipos funcionales, recopilan opiniones, iteran sobre la interfaz de usuario y optimizan funcionalidades, todo ello sin llegar nunca a confirmar si están resolviendo un problema que realmente merece la pena solucionar.

Entonces, ¿qué deberían hacer de forma diferente los gestores de producto? La respuesta no es «usar menos IA». Es «usar la IA en la secuencia correcta».

Las ventajas del vibe coding son reales: velocidad, accesibilidad e iteración

Nada de esto es un argumento en contra de la IA. Más bien al contrario. Las ganancias en productividad son extraordinarias:

Democratización de la creación. los product managers sin perfil técnico ahora pueden construir prototipos funcionales sin esperar a los sprints de ingeniería, lo que reduce los cuellos de botella y aporta ventajas de rapidez y reducción de costes.

Reducción radical del coste de iteración. Se pueden crear y descartar prototipos desechables sin consumir capacidad de ingeniería, reservando el tiempo de los desarrolladores para tareas de nivel de producción. Pero el mayor avance es reducir el coste de equivocarse. Los equipos pueden probar diez conceptos en lugar de dos, las variaciones de UX se vuelven desechables y los experimentos se multiplican. Esto aumenta la opcionalidad, lo que constituye una enorme ventaja estratégica.

Mejor comunicación entre áreas. El software funcional actúa como una «especificación viva» que alinea a las partes interesadas de manera más eficaz que los documentos estáticos, reduciendo las malas interpretaciones. Los prototipos funcionales eliminan la ambigüedad porque, en lugar de debatir especificaciones, ingenieros, diseñadores, equipos de ventas y clientes reaccionan ante algo tangible. Las conversaciones se enriquecen porque todos hablan sobre el mismo elemento concreto.

Ciclos de aprendizaje más rápidos. La filosofía Lean Startup hacía hincapié en el ciclo Construir-Medir-Aprender. El ciclo de retroalimentación entre la idea y el producto tangible se reduce de semanas a horas, permitiendo a los equipos probar más hipótesis en menos tiempo. En teoría, esto debería acelerar drásticamente el aprendizaje. La frase clave es «en teoría» porque muchos equipos sustituyen accidentalmente el aprendizaje por el lanzamiento.

Las desventajas ocultas: sesgo cognitivo y optimización prematura

Los riesgos son más sutiles que las alucinaciones o el código con errores. Son de naturaleza cognitiva.

La trampa de la confianza. Los prototipos visualmente atractivos generan una falsa sensación de certeza. Los seres humanos sobreestiman sistemáticamente las ideas una vez que se materializan. Una maqueta en Figma parece más real que las notas de una entrevista. Una aplicación funcional resulta más creíble que una investigación etnográfica. Una vez que existe un prototipo, el anclaje cognitivo dificulta abandonarlo, incluso cuando la investigación con usuarios sugiere que el problema subyacente es distinto al que se había asumido. La IA amplifica este sesgo al permitir crear elementos pulidos sin apenas esfuerzo. Esta ilusión de progreso, oculta el hecho de que no se ha producido ningún aprendizaje real sobre las necesidades del cliente.

Inflación de funcionalidades. Cuando construir resulta casi gratuito, es más difícil mantener la contención. En lugar de preguntarse «¿Cuál es el experimento más sencillo posible?», los equipos se preguntan «¿Qué más podemos añadir?». Los equipos pasan horas ajustando la ubicación de los botones, las combinaciones de colores y los detalles del flujo de trabajo antes de confirmar si los usuarios realmente desean esa funcionalidad. Irónicamente, un desarrollo de bajo coste suele dar lugar a productos más complejos.

Pérdida de competencias en la fase de descubrimiento. Quizás el mayor riesgo a largo plazo sea lo que los economistas llaman deskilling (pérdida de cualificación): perder experiencia porque las herramientas realizan la tarea por nosotros. Preocupaciones similares están surgiendo en el ámbito del trabajo intelectual, donde la IA puede crear la ilusión de competencia al tiempo que debilita el criterio subyacente. Los product managers junior pueden llegar a ser expertos en redactar prompts antes de convertirse en observadores excepcionales. Sabrán cómo generar funcionalidades, pero no cómo identificar necesidades insatisfechas: son habilidades muy diferentes. Y si nuestra comprensión del problema es confusa, la IA generará un trabajo confuso mucho más rápido y con mejor formato.

Dejemos de tratar la IA como un atajo para obtener respuestas

Usémosla para mejorar la fase de descubrimiento.

El descubrimiento nunca ha consistido en generar artefactos como personas o árboles de oportunidades. Se trata de desarrollar empatía hacia clientes reales y reducir la incertidumbre mediante el aprendizaje continuo. La IA debería potenciar ese proceso, no reemplazarlo.

La IA puede acelerar drásticamente el descubrimiento de productos, pero solo si los equipos la utilizan para profundizar en su comprensión de los clientes, y no para fabricar una falsa sensación de certeza. El papel más valioso de la IA es actuar como un copiloto de investigación: ayudando a los equipos de producto a recopilar, estructurar, cuestionar y sintetizar evidencias basadas en el comportamiento real de los clientes, al tiempo que se preserva el criterio humano.

En el siguiente post hablaremos de cómo utilizar la IA para el descubrimiento de problemas.

El post “Vibe coding y el espejismo de la velocidad (2)” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Product Management de productos tecnológicos y Product Marketing de productos tecnológicos te pueden ayudar.]

Deja un comentario

El auge del “vibe coding” impulsado por IA ha democratizado la creación de software, pero al mismo tiempo está erosionando la disciplina más crítica en la gestión de productos: el descubrimiento de problemas.

Cada cierto tiempo, surge una nueva herramienta que promete liberar a los equipos de desarrollo de producto software de la fricción. Agile iba a solucionar los problemas de implementación. Design Thinking iba a mejorar la empatía en la definición del producto. El no-code iba a democratizar la creación. Ahora, tenemos la IA generativa y el vibe coding: la capacidad de describir la visión de un producto software en lenguaje natural y ver cómo una aplicación se materializa en tiempo real.

El vibe coding, que consiste en describir lo que se desea en lenguaje sencillo y dejar que la IA genere prototipos funcionales, ha reducido drásticamente el tiempo desde la idea hasta el software operativo, de semanas a horas. Los product managers ahora pueden usar herramientas como Cursor, Claude, Lovable, Bolt o Replit y observar cómo la IA construye interfaces de usuario, implementa la lógica básica y despliega aplicaciones interactivas en un santiamén.

Usando estas herramientas, las interfaces aparecen al instante, las bases de datos se configuran automáticamente, la autenticación, las API, los paneles de control y los flujos de trabajo surgen a partir de instrucciones en lenguaje natural y una buena dosis de iteración. Hemos entrado en la era del vibe coding: crear software describiendo la intención en lugar de escribir código.

Los product managers están, con razón, fascinados. El vibe coding parece magia y otorga una ventaja indiscutible. Muchos celebran esto como la democratización de la creación de productos. Pero también puede ser una trampa.

El atractivo de la velocidad en la construcción de soluciones

Con las herramientas de IA actuales, desarrollar software se ha vuelto más barato que comprender a los clientes. Esto es extraordinario y, a la vez, profundamente peligroso. Porque esta velocidad tiene un coste oculto: anima a los equipos de producto a saltarse el trabajo engorroso e incierto de comprender el problema y a pasar directamente al modo de solución. Esta es la paradoja de la IA: reduce el coste de desarrollo de forma tan drástica que omitir la fase de investigación parece racional.

El prototipo se convierte en prueba de progreso: los inversores quedan impresionados, los ejecutivos aplauden, los diseñadores iteran y los ingenieros refinan. Mientras tanto, nadie ha respondido a la única pregunta que importa: ¿Se está solucionando el problema correcto?

El vibe coding ha llevado a la industria del software a una encrucijada crucial. El verdadero peligro de la IA en la gestión de productos no reside en que la creación de software se vuelva sencilla, sino en que la extrema velocidad en el espacio de la solución nos ciega ante el trabajo fundamental necesario en el espacio del problema.

Casos de uso: donde el vibe coding destaca (y donde falla)

Aplicaciones eficaces

El vibe coding sobresale en escenarios específicos donde el problema se comprende bien y el objetivo es explorar rápidamente distintos enfoques de implementación:

  • Herramientas internas y dashboards: cuando los usuarios son compañeros que pueden explicar sus flujos de trabajo, los prototipos generados por IA aceleran el alineamiento sobre las necesidades de visualización de datos y generación de informes.
  • Validación de sistemas de diseño: los product managers pueden generar rápidamente múltiples variantes de interfaz para probar patrones de interacción antes de asignar recursos de ingeniería.
  • Comunicación con las partes interesadas: un prototipo funcional transmite la visión de manera más eficaz que un documento de requisitos (PRD) de 20 páginas, lo que ayuda a conseguir los apoyos necesarios y a identificar suposiciones desde una etapa temprana.
  • Experimentos con microfuncionalidades: es posible crear prototipos y probar en un solo día funcionalidades pequeñas y acotadas (por ejemplo, «una pantalla única que muestre a los nuevos usuarios las tres primeras acciones que deben realizar»).

Aplicaciones arriesgadas

Esa misma velocidad se convierte en un inconveniente cuando se aplica a problemas ambiguos:

  • Entrada en nuevos mercados: crear un prototipo antes de realizar entrevistas con clientes genera una falsa confianza basada en suposiciones no validadas.
  • Rediseño de flujos de trabajo complejos: los prototipos generados por IA suelen optimizarse buscando la elegancia técnica en lugar del comportamiento real del usuario, lo que lleva a los equipos a perfeccionar soluciones que nadie necesita.
  • Decisiones a nivel de plataforma: las decisiones de arquitectura (permisos, modelos de datos, puntos de integración) requieren un contexto profundo que la IA no puede inferir a partir de instrucciones vagas.

Vibe coding y product management

Todos los equipos de producto conocen el sesgo de confirmación. En el campo del product management esto se puede traducir en que una vez que creemos que una idea es buena, inconscientemente buscamos evidencia que la respalde.

Vibe coding y descubrimiento de producto

El vibe coding altera fundamentalmente el ciclo de descubrimiento de producto (problema + solución):

  • Sin vibe coding, el proceso empieza comprendiendo el espacio del problema mediante investigación y generación de insights, para posteriormente generar ideas de solución que materializan en prototipos que son validados.
  • Con vibe coding el proceso empieza con una idea (y en las empresas nunca faltan fuentes de ideas) que se materializa inmediatamente en un prototipo de solución generado mediante IA. Posteriormente este prototipo se evalúa y mejora mediante su uso práctico y se valida.

Pero cuanto más fácil resulta crear soluciones, más difícil resulta mantener la curiosidad por los problemas. En lugar de explorar los problemas abiertamente, los equipos comienzan a validar un producto con el que ya se han comprometido emocionalmente. Los psicólogos llaman a esto anclaje. Los gerentes de producto deberían llamarlo costes y riesgos.

Como bien observó Steve Johnson, veterano del sector, la IA no sustituye la gestión de productos; revela si alguna vez la aprendimos. La IA es un amplificador: si nuestro pensamiento estratégico es claro, la IA nos otorga capacidades extraordinarias. Si nuestros fundamentos de product management son débiles, la IA simplemente nos permite crear algo incorrecto más rápido que nunca, con una interfaz de usuario impecable y un código perfectamente formateado.

La verdadera labor de la gestión de productos siempre ha consistido en reducir la incertidumbre. Un product manager existe para responder preguntas que ninguna IA puede actualmente resolver por sí sola:

  • ¿Qué problema del cliente merece la pena resolver?
  • ¿Cuán grave es?
  • ¿Quién lo experimenta con mayor intensidad?
  • ¿Qué alternativas existen ya?
  • ¿Por qué los clientes actúan de forma distinta a como dicen hacerlo?

No son problemas de documentación. Son problemas de juicio y comprensión profunda. Y esa comprensión sigue requiriendo de seres humanos.

La mayoría de los marcos sobre product management distinguen dos mundos: espacio del problema y espacio de la solución. La IA acelera enormemente el segundo.

Pero la ventaja competitiva reside cada vez más en el primero. ¿Por qué? Porque las soluciones se están convirtiendo en productos indiferenciados. Comprender a las personas, no. A medida que crear software resulta más sencillo, el recurso escaso deja de ser la capacidad de ingeniería y pasa a ser el conocimiento profundo del cliente.

En el siguiente post seguiremos hablando de los dilemas que crea el vibe coding.

El post “Vibe coding y el espejismo de la velocidad (1)” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Product Management de productos tecnológicos y Product Marketing de productos tecnológicos te pueden ayudar.]

Deja un comentario

La implementación de productos de IA difiere de los productos tradicionales en que requiere una mayor variedad de perfiles involucrados, es más iterativa (debido a la necesidad de seleccionar, ajustar y evaluar modelos) y debe proporcionar al producto componentes de control, evolución y explicabilidad.

Seguimos analizando cómo difieren las actividades de desarrollo en productos basados en AI frente a los tradicionales.

El equipo de Implementación construye la solución a partir de los requisitos y las especificaciones generadas durante la Definición y Diseño de producto. Como paso fundamental de esta actividad el equipo crea una especificación técnica que describe la arquitectura y la construcción interna de la solución. El objetivo es llegar a una “unidad cero” del producto que garantice la replicabilidad/fabricabilidad, la calidad, la escalabilidad en las prestaciones, la posibilidad de evolución y la adaptabilidad (en su caso) del producto a diferentes segmentos de clientes.

Dado que la IA consiste esencialmente en software, la implementación de estos productos se suele instrumentar como uno -o varios- proyectos que se gestionan y ejecutan, dependiendo del escenario, usando técnicas y herramientas tales como:

  • Desarrollo ágil.
  • Desarrollo en cascada.
  • Herramientas Low-code o No-code.
  • Desarrollo asistido por AI.

Waterfal vs Agile

Sobre este último punto, mucho se ha venido hablando recientemente sobre el «vibe coding”: utilizar la IA para generar código a partir de instrucciones en lenguaje natural. Y es que el enfoque ofrece ventajas, pero requiere una aplicación cuidadosa.

Ventajas:

  • Rapidez: permite la creación rápida de prototipos y aplicaciones básicas.
  • Accesibilidad: reduce la barrera para que los no programadores desarrollen sus ideas.
  • Aumento de la creatividad: libera a los desarrolladores para que se centren más en la arquitectura que en la sintaxis.

Inconvenientes:

  • Calidad del código: el código generado por IA puede no estar optimizado o introducir alucinaciones y deuda técnica.
  • Retos de depuración: corregir el código opaco de la IA puede requerir muchos esfuerzo.
  • Riesgos de seguridad: el código no probado puede incluir vulnerabilidades.

Por eso de momento el “vibe coding” está indicado en los siguientes casos:

  • Creación de prototipos: Ideal para MVP o proyectos de prueba de concepto.
  • Funciones y características no críticas: componentes de interfaz de usuario sencillos o código repetitivo.

Las diferencias más importantes entre productos de IA y tradicionales en el área de Implementación de producto son:

  • Proceso de desarrollo y composición del equipo. En el desarrollo de la IA participan científicos de datos, ingenieros de aprendizaje automático y evaluadores de modelos junto con ingenieros de software tradicionales. El equipo debe colaborar en la construcción de modelos, la ingeniería de datos y la integración de software. Esto hace que el proceso sea más iterativo, ya que los modelos se ajustan y prueban, y suele requerir conocimientos especializados en marcos de aprendizaje automático, pipelines de datos y herramientas de despliegue.
  • Recopilación y preparación de datos. Una parte importante de la fase de implementación se dedica a recopilar, limpiar, etiquetar y transformar los datos. La calidad de los datos, el preprocesamiento y la ingeniería de características son pasos críticos, ya que el rendimiento del modelo de IA depende en gran medida de la precisión, relevancia e integridad de los datos. Esta fase suele ser la que más tiempo requiere y exige recursos específicos de ingeniería de datos.
  • Selección, entrenamiento y ajuste de modelos. La implementación de la IA implica seleccionar y experimentar con diferentes modelos, algoritmos de entrenamiento y ajuste de hiperparámetros para optimizar el rendimiento. El entrenamiento de un modelo de IA es un proceso iterativo, que requiere ensayo y error y evaluaciones periódicas del rendimiento utilizando métricas como la exactitud, la precisión, la cobertura y el valor F1. Este proceso puede llevar días, semanas o incluso más tiempo, dependiendo de la complejidad del modelo y de los datos.
  • Prototipado, experimentación y evaluación de modelos. La experimentación es fundamental, ya que el rendimiento del modelo puede variar significativamente en función de los hiperparámetros y las configuraciones de los datos. Durante la implementación, los desarrolladores evalúan continuamente el rendimiento del modelo frente a conjuntos de validación, ajustando el modelo o los datos según sea necesario. La evaluación del modelo también tiene en cuenta la imparcialidad, el sesgo y la interpretabilidad, lo que requiere métricas y pruebas adicionales para garantizar un uso ético.
  • Pruebas y validación. Además de las pruebas tradicionales, los productos de IA requieren una validación exhaustiva de la precisión predictiva y la generalizabilidad del modelo. Esto implica pruebas de rendimiento en conjuntos de entrenamiento, validación y pruebas no vistos previamente para evitar el sobreajuste. La validación incluye el tratamiento de casos extremos, el análisis del sesgo del modelo y la garantía de robustez en condiciones de datos variadas. Estas pruebas son continuas, ya que puede ser necesario volver a entrenar los modelos si cambia la distribución de los datos.
  • Implantación e integración continua. El despliegue implica la creación de entornos y canales que permitan la integración continua, el reentrenamiento de modelos y la supervisión periódica de los mismos. Puede que sea necesario volver a entrenar los modelos a medida que se disponga de nuevos datos, por lo que el despliegue incluye mecanismos para el reentrenamiento y el redespliegue automáticos, así como herramientas para supervisar la deriva (drift), la precisión y el rendimiento de los modelos. A menudo se utilizan marcos MLOps, que facilitan este flujo de trabajo.
  • Control y gestión de errores. La gestión de errores en la IA incluye la supervisión de problemas como la desviación del modelo, la disminución del rendimiento o las predicciones anómalas. Para ello, es necesario implantar herramientas de supervisión que monitoricen los cambios en la precisión o confianza del modelo a lo largo del tiempo y alerten a los desarrolladores si el rendimiento del modelo disminuye. Los sistemas de IA también pueden requerir mecanismos adicionales de realimentación del usuario para capturar resultados inesperados.
  • Interfaz de usuario para los resultados e interpretabilidad de la IA. A menudo, la interfaz de usuario debe acomodar los resultados probabilísticos mostrando puntuaciones de confianza, explicaciones o sugerencias alternativas. La aplicación requiere el diseño de interfaces intuitivas que ayuden a los usuarios a comprender e interpretar las predicciones de la IA, especialmente en aplicaciones críticas. También pueden integrarse técnicas de IA Explicable (XAI), lo que puede añadir complejidad al desarrollo tanto del front-end como del back-end.
  • Seguridad y privacidad. La implementación implica una mayor atención a la privacidad, especialmente en torno a la recopilación de datos, el almacenamiento y al entrenamiento de modelos. El acceso a los pipelines de datos, los modelos de entrenamiento y los resultados debe ser seguro para evitar fugas de datos o accesos no autorizados. Garantizar el cumplimiento de las leyes de privacidad (por ejemplo, GDPR) es a menudo más difícil porque los modelos de IA procesan con frecuencia datos personales sensibles.
  • Mantenimiento continuo y gestión de modelos. Los productos de IA requieren un seguimiento, una evaluación y un reentrenamiento continuos para mantener la exactitud y la relevancia del modelo. La recopilación continua de datos y los bucles de realimentación pueden ser necesarios para detectar la desviación del modelo o adaptarse a patrones cambiantes. A menudo se aplican prácticas de MLOps para agilizar este ciclo de vida, garantizando que los modelos sigan siendo exactos y útiles a lo largo del tiempo.

Muy importante: riesgo de Factibilidad

La IA es, por su propia naturaleza, no determinista. No tenemos ninguna garantía de que va a funcionar adecuadamente para resolver el problema de mercado que queremos resolver. Una tecnología que puede personalizar un feed de noticias con una tasa de error aceptable puede resultar totalmente inadecuada para dosificar un medicamento. La disponibilidad de datos de entrenamiento en cantidad y con calidad es un aspecto primordial a este respecto.

Por eso para evitar el riesgo de factibilidad están cobrando más importancia los prototipos y pruebas de concepto construidos mediante asistencia de IA.

En el próximo post analizaremos si a los clientes les importa realmente nuestra nueva funcionalidad de IA.

El post “Productos basados en IA vs. tradicionales: implementación de producto” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Product Management de productos tecnológicos y Product Marketing de productos tecnológicos te pueden ayudar.]

Deja un comentario

El diseño de productos de IA difiere de los productos tradicionales en que debe proporcionar la funcionalidad y la experiencia de uso necesarias para que los usuarios puedan manejar los resultados inciertos y probabilísticos de la IA, les aporten transparencia y confianza, incorporen la realimentación y la mejora continua y proporcionen un comportamiento ético y cumplimiento normativo.

Seguimos analizando cómo difieren las actividades de desarrollo en productos basados en AI frente a los tradicionales.

Una vez realizada, al menos de una manera preliminar, la Definición de nuestro producto (y acotado y articulado el problema de mercado a resolver), Diseño de Producto se encarga de conceptualizar la solución a dicho problema, de formular y validar su propuesta de valor y de especificar el producto desde el punto de vista funcional y de experiencia de usuario.

Para ello aplica inicialmente un proceso divergente de generación de múltiples ideas de solución que posteriormente se someten a un proceso iterativo de prototipado y prueba para converger hacia una única solución adecuada en términos de deseabilidad, utilidad y usabilidad. Diseño elabora storyboards, diagramas de flujo, wireframes, prototipos y otros artefactos que se van iterando y validando con los clientes para asegurar que la solución es aceptable desde los puntos de vista funcional y experiencial.

Como resultado, Diseño elabora las especificaciones a partir de las cuales el equipo de Implementación construirá la solución real. Se trata de especificaciones funcionales y de experiencia de usuario -no de especificaciones técnicas- que describen cómo funciona el producto desde la perspectiva de comprador y usuario. Esta especificación puede tomar diversas formas: desde el tradicional Documento de Especificaciones de Producto hasta un prototipo “de alta fidelidad” anotado con historias de uso.

Las diferencias más importantes entre productos de IA y tradicionales en el área de Diseño de producto son:

  • Ideación. La fase de ideación hace hincapié en la identificación de soluciones que puedan implementarse específicamente utilizando capacidades de IA, como el análisis predictivo, la automatización o la personalización. Los diseñadores deben valorar la viabilidad del uso de la IA evaluando la disponibilidad de datos, las posibilidades algorítmicas y las limitaciones técnicas. Esto aboga por una involucración temprana del equipo de Implementación (ingeniería) en esta fase.
  • Manejo de la incertidumbre y los resultados probabilísticos. La IA suele proporcionar resultados probabilísticos que conllevan incertidumbre. El diseño en IA requiere el diseño de interfaces que puedan comunicar estas incertidumbres de forma eficaz, por ejemplo, mostrando los niveles de confianza o utilizando señales visuales para indicar la variabilidad de las predicciones. Los usuarios deben ser conscientes de que los resultados de la IA pueden no ser precisos al 100% y cambiar con el tiempo.
  • Educar a los usuarios sobre las capacidades y limitaciones de la IA. Los diseñadores deben informar a los usuarios de lo que la IA puede y no puede hacer, así como de las limitaciones de sus datos o algoritmos. Los esfuerzos del diseño a menudo implican procesos de onboarding, información sobre herramientas o señales visuales que informan a los usuarios sobre los puntos fuertes y débiles de la IA y los contextos en los que podría ser menos fiable.
  • Satisfacer las necesidades de los usuarios en materia de transparencia en la toma de decisiones. Los usuarios a menudo necesitan entender cómo la IA llega a sus conclusiones, especialmente en contextos de alto riesgo como la sanidad, las finanzas o la selección de personal. Esto hace que el diseño se centre en la transparencia y la capacidad de explicación. Los product managers y los diseñadores pueden tener que crear funciones que permitan a los usuarios ver las puntuaciones de confianza, las razones de las predicciones de la IA u otros datos sobre el «pensamiento» de la IA.
  • Crear confianza en las predicciones de la IA. La creación de confianza es una parte fundamental del diseño para la IA, ya que los usuarios pueden desconfiar de las recomendaciones o decisiones basadas en la IA. Los diseñadores deben crear interfaces y experiencias que ayuden a los usuarios a confiar en la precisión y fiabilidad de la IA, sobre todo para aplicaciones en ámbitos delicados.
  • Realimentación iterativa del usuario y mejora del rendimiento. Dado que los modelos de IA suelen entrenarse y mejorarse con los datos de los usuarios, la recopilación de sus opiniones es fundamental para la optimización continua. El diseño para la IA implica la creación de mecanismos para recabar opiniones que puedan mejorar directamente el rendimiento, la precisión o la relevancia del modelo a lo largo del tiempo, alimentando la lógica central del producto en tiempo real.
  • Pruebas contextuales y validación de usuario. El diseño para la IA requiere pruebas de usuario rigurosas para comprender cómo interactúan los usuarios con los resultados probabilísticos y el comportamiento impredecible. Las pruebas pueden incluir el examen de la tolerancia de los usuarios a la incertidumbre, su comprensión de las explicaciones proporcionadas y su comodidad a la hora de tomar decisiones basadas en las sugerencias de la IA.
  • Diseño para un uso ético y justo de la IA. La IA a veces puede reforzar los prejuicios, por lo que el diseño debe incluir consideraciones de equidad e inclusión. Esto puede significar diseñar con transparencia las fuentes de datos, permitir a los usuarios señalar resultados sesgados y posibilitar la revisión o auditoría de las decisiones de la IA. El diseño ético es fundamental para generar confianza y reducir los daños, especialmente en aplicaciones que afectan a la vida de las personas.
  • Adaptación continua de la UX a los cambios de modelo. Los modelos de IA pueden evolucionar con el tiempo a medida que se reentrenan con nuevos datos, lo que puede cambiar el comportamiento o el rendimiento del sistema. El diseño centrado en el usuario para la IA implica el diseño de interfaces adaptables que puedan dar cabida a cambios en la funcionalidad o el comportamiento debidos a actualizaciones del modelo, y puede ser necesario informar a los usuarios de estos cambios.
  • Requisitos reglamentarios y de conformidad. El cumplimiento de la normativa suele ser más complejo, sobre todo en sectores con directrices estrictas sobre el uso de datos, la transparencia y la imparcialidad (por ejemplo, sanidad, finanzas y seguros). El diseño debe incorporar una comprensión de cómo afectan las normativas a la recopilación de datos, el procesamiento y el despliegue de modelos, especialmente si el producto afecta a áreas personales o sensibles de la vida de los usuarios.
  • Prototipos y experimentación. Los anteriores puntos amplían el ámbito y la dificultad de las tareas de diseño de productos basados en AI y expanden el alcance de las actividades de prototipado y experimentación, claves en esta fase.

Muy importante: riesgo de Usabilidad

La experiencia del cliente es importante para cualquier producto, pero con la IA adquiere un nuevo nivel de importancia y complejidad. Para los productos de IA, necesitamos diseñar experiencias de usuario que establezcan claramente las expectativas sobre lo que la tecnología puede y no puede hacer y, al menos conceptualmente, cómo funciona el producto. Esta transparencia es clave para generar confianza y evitar la frustración al encontrar limitaciones. La explicabilidad de la IA es un componente clave de esta transparencia y confianza.

En el próximo post cubriremos las actividades de implementación  de productos de IA vs. tradicionales.

El post “Productos basados en IA vs. tradicionales: diseño de producto” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Product Management de productos tecnológicos y Product Marketing de productos tecnológicos te pueden ayudar.]

Deja un comentario

La definición de productos de IA difiere de los productos tradicionales en la mayor dificultad para elegir problemas de mercado que la IA pueda resolver de manera útil, en la comprensión y el modelado de la respuesta de compradores y usuarios ante la IA y la articulación de requisitos en áreas específicas relacionadas con la IA.

Seguimos analizando cómo difieren las actividades de desarrollo en productos basados en AI frente a los tradicionales.

Una vez elegida/s nuestra/s oportunidad/es de mercado prioritaria/s, las actividades de Definición de producto consisten en acotar y articular nuestro espacio del problema.

Típicamente aplicaremos primero un pensamiento divergente para explorar ese espacio para finalmente converger en el problema específico que vamos a resolver con nuestro producto (y para quién lo vamos a resolver). Por lo tanto la Definición de producto se circunscribe específicamente al espacio del problema frente al Diseño o la Implementación, que se inscriben en el espacio de la solución.

Y una vez acotado dicho problema a resolver lo modelaremos y articularemos mediante artefactos accionables, entre ellos:

  • Personas o arquetipos, tanto de compradores como de usuarios.
  • Escenarios de compra y uso.
  • Requisitos, que son expresiones de problema agnósticas respecto a la solución y que pueden tomar diversas formas, incluyendo Jobs-To-Be-Done.

Las diferencias más importantes entre productos de IA y tradicionales en el área de Definición de producto son:

  • Selección de problemas de mercado. La selección de problemas de mercado para los productos basados en IA requiere identificar los problemas que se resuelven mejor mediante el reconocimiento de patrones, las predicciones o la clasificación en lugar de la lógica determinista. Los problemas adecuados para la IA suelen implicar conjuntos de datos grandes y complejos o requerir una toma de decisiones automatizada a gran escala. Además, es fundamental tener en cuenta si los datos están disponibles, son de alta calidad e insesgados, ya que son fundamentales para crear una solución de IA útil.
  • Definición del problema y análisis inicial de factibilidad. El descubrimiento suele comenzar con la evaluación de si la IA puede abordar realmente el problema. Esto incluye evaluar si hay suficientes datos de alta calidad disponibles, si los patrones de los datos coinciden con el problema y si el aprendizaje automático es adecuado. A menudo, los estudios de viabilidad de la ciencia de datos o los modelos rápidos de prueba de concepto (POC) se crean al principio para probar si una solución de IA es factible. Si la calidad o disponibilidad de los datos no es suficiente, es posible que la solución de IA no sea factible.
  • Necesidades y expectativas de los usuarios. Las necesidades y expectativas de los usuarios incluyen preocupaciones sobre la transparencia, explicabilidad y fiabilidad de la IA. Durante la definición se hace especial hincapié en saber hasta qué punto se sienten cómodos los usuarios con los resultados de la IA, sobre todo en ámbitos que requieren interpretabilidad (por ejemplo, las finanzas o la atención sanitaria). Los usuarios pueden necesitar garantías sobre cómo llega la IA a sus conclusiones, por lo que el descubrimiento debe identificar características que aumenten la confianza, como puntuaciones de confianza o explicaciones de las predicciones.
  • Modelado de personas de usuarios y compradores. Las personas de productos de IA a menudo deben incluir un conocimiento más profundo de la familiaridad de los usuarios con la IA, sus expectativas de transparencia en la toma de decisiones y su confianza en las predicciones de la IA. Estas personas deben ampliarse respecto a las de productos tradicionales para tener en cuenta hasta qué punto los usuarios necesitan comprender el razonamiento de la IA, el nivel de autonomía que desean tener sobre los resultados de la IA y si se sienten cómodos con la incertidumbre. Esto añade complejidad al desarrollo de las personas, especialmente en campos en los que los resultados de la IA influyen en decisiones críticas (por ejemplo, finanzas, sanidad).
  • Caracterización de escenarios de uso. Los escenarios de los productos basados en IA deben tener en cuenta una serie de resultados probables y las acciones del usuario asociadas. Esto significa definir escenarios no sólo para el comportamiento previsto de la IA, sino también para los casos en que las predicciones pueden ser inciertas, ambiguas o incorrectas. Los product managers suelen crear escenarios en los que los usuarios interpretan, verifican o ajustan las recomendaciones de la IA, lo que añade complejidad a los viajes del usuario.
  • Definición de los requisitos del producto. Aparte de los requisitos funcionales los requisitos de los productos basados en IA incluyen la definición de fuentes de datos, umbrales de precisión, métricas de rendimiento (por ejemplo, precisión, cobertura, F1) y consideraciones éticas como la imparcialidad y la transparencia. Los requisitos también pueden abarcar bucles de retroalimentación del usuario para el reentrenamiento del modelo e interfaces para mostrar puntuaciones de confianza o razonamientos. Esto exige una mezcla de requisitos técnicos, éticos y de usabilidad, lo que hace que el proceso sea más interdisciplinar.
  • Consideraciones sobre datos y privacidad. Definir un producto de IA implica evaluar la disponibilidad de datos, las implicaciones para la privacidad y las restricciones normativas, especialmente en el caso de datos sensibles para el usuario. Los requisitos pueden incluir la definición de cómo se obtienen, almacenan y utilizan los datos para entrenar modelos sin violar las normas de privacidad o introducir sesgos. Además, los requisitos pueden esbozar procesos para la curación continua de los datos y la supervisión de la desviación (drift) o sesgo del modelo.

Muy importante: riesgo de Utilidad

El valor es siempre un riesgo crítico.  Los productos basados en IA prometen un valor significativo, razón por la cual todos nos estamos apresurando a aplicar esta tecnología.  Pero también podemos ver hoy muchos ejemplos de productos de IA que sólo lo son de nombre.  Así pues, la primera responsabilidad del product manager de IA es garantizar que las funciones y los productos impulsados por la IA aporten un valor genuino y diferencial a los usuarios y clientes. Pero no sólo se trata de entregar valor, también tenemos que colaborar estrechamente con el departamento de marketing del producto para asegurarnos de que podemos comunicar este valor de forma eficaz.

En el próximo post cubriremos las actividades de diseño de productos de IA vs. tradicionales.

El post “Productos basados en IA vs. tradicionales: definición de producto” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Product Management de productos tecnológicos y Product Marketing de productos tecnológicos te pueden ayudar.]

Deja un comentario

El análisis de oportunidades de mercado para productos de IA difiere de los productos tradicionales en su mayor dificultad para identificar dichas oportunidades, evaluar el problema de mercado a resolver y el valor que aporta nuestra solución.

Seguimos analizando cómo difiere la gestión de productos basados en IA frente a los tradicionales, centrándonos en este post en el Análisis de Oportunidades de Mercado.

En esta serie de posts abogamos por un proceso para analizar oportunidades de mercado dividido en las siguientes fases:

  1. Identificación de oportunidades de mercado. ¿Qué oportunidades de mercado existen para nosotros?
  2. Evaluación de oportunidades de mercado. ¿Cuáles son las oportunidades de mercado más interesantes para nosotros?
  3. Priorización de oportunidades de mercado. ¿En cuáles de esas oportunidades de mercado deberíamos enfocarnos?

Es importante implementar un proceso sistemático de análisis de oportunidades de mercado porque nos obliga a explorar alternativas, favorece una toma de decisiones basadas en datos y fomenta el enfoque estratégico.

Análisis de Oportrunidades de Mercado

Este proceso nos evita jugar a la «ruleta del mercado objetivo» y el dolor de tener que pivotar más adelante por no haber analizado mínimamente con antelación nuestras posibles oportunidades.

Desde ese punto de vista, las diferencias más importantes entre productos de IA y tradicionales en el área de Análisis de Oportunidades de Mercado son:

  • Identificación de oportunidades de mercado. Como todas las tecnologías altamente disruptivas, la IA permite resolver problemas que hasta ese momento parecían irresolubles o se manejaban ineficientemente aplicando soluciones pedestres o enormes cantidades de trabajo humano. Por eso la IA no sólo va a mejorar productos existentes, sino a generar categorías de productos totalmente nuevas. Por lo tanto, nuestra identificación de oportunidades de mercado no puede centrarse sólo en necesidades conocidas y expresadas sino en necesidades nuevas, no articuladas, no reconocidas, latentes o inconscientes. Las técnicas de creatividad e ideación, y las técnicas no convencionales de comprensión de los clientes serán imprescindibles no sólo para encontrar aplicaciones a la tecnología (technology-push) sino para descubrir esas nuevas necesidades (market-pull).
  • Evaluación del problema de mercado a resolver. Uno de los primeros aspectos de la evaluación de una oportunidad de mercado es entender la importancia, urgencia y extensión del problema a resolver, la disposición de los clientes a pagar para resolverlo, etc. Dado que, como hemos mencionado, muchos de los problemas que resuelve la IA son “nuevos” necesitaremos de técnicas sofisticadas para cuantificarlos como, por ejemplo, el descubrimiento empático y la experimentación en el mercado (exponiendo a los clientes a prototipos de soluciones).
  • Estimación del tamaño actual y crecimiento futuro del mercado. Nuevamente, dado que la IA puede crear oportunidades de mercado totalmente nuevas, la estimación de su tamaño puede resultar difícil. Máxime, teniendo en cuenta que tendrán que producirse los inevitables procesos sociales de difusión de la innovación. Establecer analogías con mercados similares, la opinión de expertos externos o la experimentación en el mercado pueden ayudarnos para este propósito.
  • Evaluación del nivel de competencia del mercado. En el caso de nuevos mercados generados por la IA la competencia puede no estar en productos similares, sino en la propia mente humana. Tengamos en cuenta los altos costes de desarrollo y explotación de sistemas de IA, las dificultades en el uso y los retos en la adopción de esos productos y su inadecuación en escenarios donde la “exactitud” es imprescindible y la indudable superioridad de la mente humana en algunas tareas cognitivas y descubriremos en ella a un competidor extraordinario. En cuanto a la competencia creada por productos similares, debemos tener en cuenta las barreras de entrada basadas en la adquisición de datos y la capacidad de crear y mantener modelos de alto rendimiento.
  • Comprensión del valor que aporta nuestra solución. El comportamiento impredecible (incluyendo la tendencia a las “alucinaciones”) de los productos basados en IA, unas métricas de rendimiento complejas y los retos en el uso de estos productos (entre otras causas, por falta de transparencia) hacen que pueda resultar complicado cuantificar el valor efectivamente entregado a sus clientes.
  • Análisis de nuestra capacidad para entregar una solución. La dependencia de la disponibilidad de datos, la incertidumbre en los entregables, los altos costes de desarrollo y explotación, la dificultad en su mantenimiento y evolución, el peligro de sesgos y comportamiento discriminatorio y los retos del cumplimiento normativo pueden interponerse en nuestro objetivo de entregar una solución eficaz al problema.
  • Disponibilidad y calidad de los datos como limitadores del mercado. Los datos son fundamentales para el éxito de las soluciones de IA, por lo que la evaluación del mercado debe tener en cuenta la disponibilidad, calidad y accesibilidad de los datos pertinentes. La viabilidad de un producto depende a menudo de que existan datos suficientes, limpios e insesgados para respaldar un modelo de IA eficaz.

Muy importante: riesgo de Viabilidad

Aunque la IA encierra un inmenso potencial los retos de viabilidad empresarial suelen ser considerables, y los errores relacionados con este riesgo tienden a dominar los titulares de actualidad. Para cualquier producto, tenemos que asegurarnos de que puede comercializarse, venderse, recibir servicios, financiarse y monetizarse eficazmente, y de que es legal y cumple todas las restricciones normativas pertinentes. Pero para los productos de IA, estos riesgos de viabilidad pueden ser especialmente importantes y difíciles y es necesario abordarlos desde el primer momento. Todavía es muy pronto en términos de economía unitaria de los productos impulsados por IA, pero hoy en día los costes pueden ser bastante elevados.  Además, para varios tipos de productos, existen verdaderas dudas sobre la procedencia de los datos y los derechos de autor de los datos de entrenamiento, los sesgos en esos datos y las ramificaciones de las recomendaciones basadas en estos datos. En términos más generales, las empresas siguen trabajando para comprender las responsabilidades e implicaciones legales de ofrecer soluciones probabilísticas a los clientes. Por último, pero no por ello menos importante, las consideraciones éticas son una preocupación constante y creciente. Esto va más allá de los posibles sesgos en los datos de formación. Si los usuarios malinterpretan un resultado, o el modelo alucina de forma que crea un peligro, ¿cuáles son las ramificaciones legales, reputacionales, económicas y éticas? Como siempre, un análisis efectivo de las oportunidades de negocio debe incluir el atractivo estructural del mercado y la posición competitiva.

En el próximo post cubriremos las actividades de definición de productos de IA vs. tradicionales.

El post “Productos basados en IA vs. tradicionales: análisis de oportunidades de mercado” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Product Management de productos tecnológicos y Product Marketing de productos tecnológicos te pueden ayudar.]

Deja un comentario

El desarrollo de productos basados en inteligencia artificial (IA) es más complejo que el de los productos “tradicionales”, ya que requiere una supervisión continua de la calidad de los datos, el rendimiento de los modelos y consideraciones éticas.

La irrupción de la IA Generativa (y hace unos pocos años, del Deep Learning) ha hecho que la inteligencia artificial monopolice virtualmente la conversación sobre innovación y tecnología. Tanto es así que en el campo del Product Management el tema más relevante es la incorporación de funciones de IA en todo tipo de productos y la gestión de productos basados en IA.

Por «productos basados en IA» entendemos productos que utilizan tecnologías de inteligencia artificial para crear experiencias que resuelvan problemas a nuestros clientes. El término «IA» incluye tanto la IA tradicional, como el aprendizaje automático, como la IA generativa. Estas tecnologías permiten una amplia gama de capacidades, incluidas las recomendaciones inteligentes, las experiencias personalizadas o el emparejamiento de los dos lados en una plataforma con varias caras.

Otros ejemplos de aplicaciones de inteligencia artificial son los dispositivos domésticos inteligentes que emplean el habla y la comprensión del lenguaje natural, los sistemas de detección de fraudes y, en el caso de la IA generativa, funciones avanzadas como la creación, el resumen y la síntesis de contenidos.Análisis de oportunidades y desarrollo de productos

Cuando hablamos de «Gestión de Productos de IA» nos referimos a la creación de productos basados en IA.  Del mismo modo que «Gestión de Productos Móviles» se refiere a la creación de productos para móviles.  Y al igual que la «gestión de productos móviles» era una habilidad especialmente demandada cuando los móviles eran nuevos, y ahora se espera que la mayoría de los product managers tengan las habilidades necesarias para desarrollar productos para móviles, esperamos que ocurra lo mismo con los product managers de IA.  Dentro de unos años, esperamos que la mayoría de los directores de producto tengan que ser expertos en la creación de productos y servicios basados en IA.

En esta serie de post vamos a analizar cómo difiere la gestión de productos basados en IA frente a los tradicionales, centrándonos en las fases iniciales del Product Management: el Análisis de Oportunidades de Mercado y el Desarrollo de Productos propiamente dicho. Y lo que digamos será en general válido para productos que consisten tanto en Aplicaciones basadas en IA como en la Infraestructura de IA subyacente (ej.: modelos).

Cuando uno se aproxima a este asunto inmediatamente aparecen una serie de temas:

  • Dependencia de los datos. Los modelos de IA dependen en gran medida de la disponibilidad de grandes conjuntos de datos para su entrenamiento y mejora continua.
  • Iteratividad. Mientras que en productos tradicionales el desarrollo iterativo es una opción (muchas veces ligada e metodologías ágiles), en productos basados en IA es imprescindible: la construcción de IA implica ciclos iterativos de entrenamiento y validación en los que se evalúa continuamente el rendimiento de los modelos y se vuelve a entrenarlos con datos actualizados.
  • Incertidumbre en los entregables. Los resultados del entrenamiento de modelos de IA son inciertos y a menudo no deterministas. Es necesario tener en cuenta la posibilidad de que un modelo no cumpla los parámetros de rendimiento deseados tras el entrenamiento y requiera un ajuste o rediseño exhaustivos.
  • Métricas de rendimiento. El éxito de los productos de IA está ligado a métricas de rendimiento probabilísticas (como exactitud, precisión, F1, etc.). Estas métricas son complejas y puede ser necesario contextualizarlas para que los involucrados no técnicos las entiendan y así gestionar sus expectativas.
  • Ética, sesgos e imparcialidad. Garantizar la equidad y el uso ético de la IA es crucial. Los sistemas de IA pueden aprender inadvertidamente y reforzar los sesgos presentes en los datos de entrenamiento, lo que conduce a resultados injustos.
  • Colaboración interfuncional. La gestión de productos de IA amplía el ámbito de colaboración de los productos tradicionales, que además de involucrar a product managers, diseñadores y desarrolladores ahora se extiende a científicos de datos, ingenieros de datos, ingenieros de aprendizaje automático y expertos legales y éticos.
  • Cumplimiento normativo. Las soluciones de IA, especialmente en campos sensibles como sanidad, finanzas y legal, deben cumplir normativas estrictas (por ejemplo, el Reglamento Europeo de IA).
  • Experiencia de usuario. Es posible que los usuarios no entiendan del todo las decisiones basadas en IA, que pueden parecer opacas. Hay que crear experiencias de usuario transparentes, ofrecer explicaciones sobre las decisiones de IA y generar confianza en los usuarios.
  • Mantenimiento. Los modelos de IA pueden degradarse con el tiempo a medida que cambian los datos del mundo real, lo que conduce a la deriva (drift) del modelo. Los gestores de producto deben establecer procesos para la supervisión continua del modelo, el reciclaje periódico y la actualización para garantizar la precisión. En IA el trabajo de desarrollo evolutivo excede los típicos de corrección de errores y adición de nuevas características.
  • Costes de desarrollo y explotación. Los modelos de IA a menudo requieren recursos computacionales sustanciales para su entrenamiento, lo que puede elevar los costes de desarrollo (aunque esto parece estar cambiando últimamente). Pero durante la fase de explotación los costes de inferencia también pueden ser elevados. Los product managers deben equilibrar los gastos en infraestructura de cómputo, almacenamiento e interconexión y los consumos de energía con el retorno de la inversión del producto.
  • «Humanos en el bucle» el estado actual de las tecnologías de IA hace que la participación humana sea en muchas aplicaciones imprescindible, tanto en aprendizaje (etiquetado de datos de entrenamiento, aprendizaje por refuerzo usando feedback humano) como en explotación (dirigiendo y aumentando la IA).
  • Experimentación continua. La experimentación es fundamental para el desarrollo de la IA, donde a menudo se prueban y comparan múltiples modelos o enfoques.

En general, el desarrollo de productos basados en IA es una tarea multidisciplinar que combina la visión del producto con el rigor científico, sobre todo porque los modelos de IA aprenden y se adaptan continuamente a los nuevos datos.

Para estudiarlo vamos a utilizar nuestro modelo de Análisis de Oportunidades y Desarrollo de Productos, compuesto de un conjunto de actividades más o menos solapadas:

La Definición y el Diseño de producto recogen entre otras las actividades conocidas como “Descubrimiento de Producto” (comprobación del encaje Problema/Solución).

En el próximo post cubriremos las actividades de análisis de oportunidades de mercado para productos de IA vs. tradicionales.

El post “Productos basados en IA vs. tradicionales: desarrollo de producto” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Product Management de productos tecnológicos y Product Marketing de productos tecnológicos te pueden ayudar.]

Deja un comentario

Esa versión esencial de tu producto, que proporciona unos beneficios básicos, no es suficiente para que tenga éxito en el mercado. Para alcanzarlo es imprescindible complementar el producto con componentes adicionales que satisfagan a los clientes menos propensos a la innovación, así como con elementos que favorezcan su adopción, fomenten el crecimiento, faciliten la compra y monetización y posibiliten medir y analizar su uso.

Especialmente en empresas de producto base tecnológica (donde los ingenieros tienen un gran peso) se da mucha importancia a lo que en marketing se conoce como el “core product” (producto esencial): un conjunto mínimo de funcionalidades y características que proporcionan los beneficios básicos que los clientes desean. En productos tecnológicos esos beneficios básicos son principalmente funcionales (p.ej., el producto permite realizar una tarea o implementar un proceso) pero, como sabemos, también los hay emocionales, económicos, etc.

Los ingenieros tienden a enamorarse de sus soluciones y consideran que ese core product es suficientemente valioso como para que los clientes lo compren sin dudarlo. Sin embargo, nada hay más lejos de la realidad: el producto esencial no garantiza la adopción por el mercado ni su uso por los clientes menos innovadores y tampoco incorpora componentes de crecimiento, comprabilidad, monetización ni analítica, imprescindibles para su éxito.

Tu producto no es tu producto

Estrategia del producto completo (“whole product”)

La oferta o producto completo es un producto básico complementado con todo lo necesario para que los clientes del mercado mainstream tengan una razón convincente para comprar. La oferta completa debe permitir a los clientes “pragmáticos” obtener un valor inmediato sin tener que crear o comprar productos o servicios adicionales. Como nos dice Geoffrey Moore en “Chrossing the Chasm”, «El punto de mayor peligro en el desarrollo de un mercado emergente basado en la tecnología reside en la transición de un mercado inicial dominado por unos pocos clientes visionarios a un mercado mainstream dominado por un gran bloque de clientes que son predominantemente pragmáticos. Los pragmáticos evalúan y compran productos completos.”

Típicamente, un producto completo:

  • Es una combinación de producto esencial y productos y servicios auxiliares que resuelve un problema del cliente de principio a fin y ofrece una experiencia total al cliente.
  • Establece una conexión emocional con los clientes que trasciende el valor funcional básico de la oferta.
  • Incluye canales de distribución adaptados al cliente y modelos de negocio rentables.
  • Requiere de la colaboración entre unidades de negocio (dentro de la empresa) y entre socios (entre empresas).

Extensiones de Producto

El producto completo se consigue extendiendo el producto esencial con una serie de productos y servicios auxiliares. Y para definir estos hay que analizar la «brecha de la experiencia»:

  • La brecha de la experiencia es la distancia entre la experiencia ideal que desean los clientes y la capacidad del producto esencial para ofrecer esa experiencia.
  • Al diagnosticar esta brecha, se pueden definir los productos y servicios auxiliares que se necesitan para aumentar el producto esencial.
  • La brecha puede salvarse mediante una combinación de estrategias de «Hacer, Comprar o Aliarse».

Componentes de Adopción, Adquisición y Retención

Se podría pensar que el principal argumento para la adopción y el crecimiento de producto es el valor de éste para el cliente. Y en el fondo eso es así, pero no sólo: es posible diseñar el producto para que incluya determinados componentes que favorezcan la adopción, la adquisición y la retención. Por ejemplo:

  • Compatibilidad con los valores, experiencias, procesos e infraestructuras existentes.
  • Sencillez, evitando el feature creep y facilitando la comprensión y el uso del producto.
  • Observabilidad, haciendo el uso y los beneficios del producto visibles para los no usuarios.
  • Facilidad para probar, ofreciendo pruebas gratuitas o modelo freemium.
  • Onboarding optimizado, de modo que el cliente pueda activar, obtener valor y experimentar su «momento ajá».
  • Bucles virales, para que los ya usuarios inviten a nuevos usuarios.
  • Bucles de contenido, para que los usuarios creen contenido que nos ayuden a atraer nuevos usuarios.
  • Bucles de hábito naturales y cultivados, para fomentar que el usuario vuelva al producto.
  • Efectos de red, que hacen que el producto sea más valioso cuantos más usuarios lo utilizan.

Componentes de Comprabilidad y Monetización

Las ventas de nuestro producto dependen de quién compra (y el valor que percibe en él) y cuánto tiene que pagar. Debemos definir un modelo de precios cuyos parámetros (cantidad a pagar, conceptos de precio, drivers según los cuales escala éste y frecuencia de pago) encajen con

  • La propuesta de valor de nuestro producto, caracterizada por su frecuencia y su fricción.
  • Nuestro segmento objetivo, caracterizado por su tamaño y su disposición a pagar.
  • Nuestros canales de adquisición, caracterizados por su influencia y su coste.

Y todo ello sin olvidar que en los casos de compra compleja, donde los compradores no son los usuarios, debemos diseñar el producto de modo que sea comprable por diseño: ayude a alcanzar los objetivos de negocio de dichos compradores y les proporcione una gran experiencia de compra. Es decir, el producto:

  • Debe aportar una propuesta de valor persuasiva para los compradores.
  • La parte de la experiencia de compra que cae dentro del producto debe ser excelente.

Componentes de Medida y Analítica

Lo bueno que tienen los productos digitales es que el uso que se hace de ellos se puede medir con todo detalle, al menos potencialmente. Registrando todas esas actividades sobre el producto podemos analizar cuáles de sus características o funcionalidades son las que más éxito tienen entre los usuarios y cómo es el patrón de uso de cada segmento de usuarios. De este modo podemos tomar decisiones de roadmap, prevenir abandonos, etc.

La analítica de producto es el proceso que se utiliza para entender cómo los clientes se relacionan con nuestro producto o servicio digital. Constituye un enfoque para situar a los clientes en el centro de la empresa mediante la observación de los datos de comportamiento, la identificación de oportunidades de alto valor y la creación de experiencias excelentes.

Pero estos datos no caen del cielo y para obtener respuestas fiables y rápidas no basta con escarbar ficheros de log. Es necesario instrumentar el producto para que automáticamente registre eventos sobre todas las actividades relevantes que nos sirvan para evaluar nuestros KPIs y obtener esos insights.

El post “Tu producto NO es tu producto” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Estrategias de crecimiento en mercados tecnológicos y Product Management de productos tecnológicos te pueden ayudar.]

Deja un comentario

El foco en la satisfacción de los objetivos del usuario de nuestro producto es imprescindible pero en ocasiones no suficiente. Para afianzar el éxito de un producto hay que ampliar el punto de vista, pensando también en los compradores, en el proceso social de adopción del producto y en el uso de éste como motor de crecimiento.

Si te estás planteado seguir un curso de Diseño de Producto es muy probable que sus contenidos sean como los siguientes:

  1. Metodologías ágiles/lean: sprints de diseño.
  2. Investigación de usuarios: etnografía, personas, viajes, requisitos, JTBD.
  3. Ideación y conceptualización: creatividad, propuestas de valor.
  4. Diseño detallado: arquitectura de información, interacción y look-and-feel, prototipos e iteración.

Es decir, dentro de la clásica tríada Deseable – Factible – Viable estas enseñanzas se van a enfocar en la Deseabilidad para el usuario. Incluso probablemente van a entrar en más detalles, tratando aspectos de Utilidad o de Usabilidad para dicha persona. Pero, en definitiva, se van a centrar en que el producto realice de manera satisfactoria un trabajo valioso para el usuario.

Los problemas de satisfacer sólo a los usuarios

Pero tengo una mala noticia: centrarse en que el producto realice un trabajo valioso para el usuario no es suficiente para el éxito del producto. Especialmente en productos innovadores de compra compleja (típicamente B2B):

  • Los productos tienen que ser comprables: el usuario no es el comprador, y el producto debe satisfacer los objetivos del comprador además de realizar los trabajos para el usuario.
  • Los productos, especialmente los nuevos, tienen que adoptarse y difundirse a lo largo y ancho de todo su mercado objetivo: su ventaja relativa frente a los competidores es sólo uno de los factores que influyen.
  • Los productos tienen que ser canales de crecimiento: no basta con delegar en Marketing y Ventas el crecimiento del producto, sino que el propio producto debe incorporar bucles de crecimiento que impulsen la adquisición, retención y monetización de los clientes.

Todos estos objetivos llevan a que los productos tengan que cumplir requisitos diferentes a los que emanan únicamente del usuario (y que en algunos casos son incluso contradictorios con aquéllos).

Comprabilidad, adoptabilidad y crecimiento por diseño

Productos comprables por diseño

Si bien los usuarios finales tienen cada vez un mayor papel en la evaluación y compra de productos, en el ámbito B2B son muchos los productos donde los compradores no coinciden necesariamente con los usuarios debido a varios motivos:

Como explicamos anteriomente, para que un producto sea comprable por diseño debe

  • Aportar una propuesta de valor específica para el comprador (no sólo para el usuario) que sea atractiva.
  • Proporcionar una parte on-product de la experiencia de compra que sea excelente.

Volviendo al ejemplo del CRM, el producto puede aportar al Director Comercial un valor en cuanto a “disponer de previsiones de ventas más fiables”, “vender más” o “tener el negocio controlado” que es diferente al que proporciona a los usuarios habituales (vendedores) basado en “cumplir mi cuota” o “planificar y organizar mis actividades”.  Y el propio producto puede optimizar la experiencia y reducir la fricción de la compra, por ejemplo, ofreciendo una modalidad SaaS que permita el pago por cuotas recurrentes (minimizando la inversión) y soslayando los problemas de compatibilidad técnica (al no requerir instalación).

Productos adoptables por diseño

Para que un producto innovador sea adoptado y se difunda en su mercado no basta con que, según las percepciones de sus potenciales clientes,  ofrezca un valor superior al de las alternativas actualmente en uso (lo que en teoría de la difusión se llama “ventaja relativa”). Para facilitar esa adopción el producto tiene que contar también con las siguientes características:

  • Compatibilidad: el producto se percibe como consistente con los valores, experiencias, procesos e infraestructuras actuales. Diseñar productos que no encajan en la presente manera de trabajar de los clientes o en la infraestructura técnica existente puede ser suicida. Por eso muchos productos radicalmente innovadores aplican a su experiencia de uso una “metáfora” o analogía con procesos y tareas ya conocidas.
  • Sencillez: el producto se percibe como fácil de entender y utilizar. En productos de base tecnológica esto es especialmente relevante porque frecuentemente crean nuevos paradigmas de uso, desconocidos por los clientes, y porque, además, los ingenieros tienden a incorporar toda la funcionalidad y características posibles, provocando la temida feature creep.
  • Facilidad para probar: es el grado en que un producto puede experimentarse de forma limitada. La prueba elimina muchas incertidumbres en el potencial cliente: utilidad, usabilidad… Pero no basta con desplegar una prueba gratuita o un modelo freemium: hay que implementar los procesos de onboarding adecuados para que esa prueba sea satisfactoria.
  • Observabilidad: grado en que el uso y el impacto del producto son visibles para los demás. Obviamente esto es más fácil de conseguir en productos con un componente físico que en los que son totalmente digitales y residen en nuestro ordenador, smartphone, etc. Ejemplos paradigmáticos son las marcas visibles en artículos de moda o los audífonos conspicuamente blancos de Apple.

Productos que incorporan crecimiento por diseño

Nuestro producto no es sólo un instrumento para satisfacer las necesidades de compradores y usuarios, sino que puede ser una plataforma para el propio crecimiento de su negocio. Como hemos visto aquí, el crecimiento impulsado por el producto (Product-Led Growth) puede complementar las actividades de marketing y ventas y convertir al mismo producto en su principal canal de crecimiento.

Algunas opciones para que el producto incorpore crecimiento por diseño son:

Ciertamente, que el producto sea el principal canal de crecimiento se basa fundamentalmente en su valor para el usuario (¿cómo, si no, favorecer esa viralidad o la creación de hábitos?) pero no solo. Es necesario pensar deliberadamente con un alcance más amplio que los usuarios inmediatos para construir casos de uso para equipos, nuevos usos -inicialmente no solicitados- que aumenten la frecuencia, o incluir en el producto componentes de efectos de red.

—

En conclusión, si no tenemos en cuenta estos factores de comprabilidad, adopción y crecimiento caeremos en la miopía de la satisfacción del usuario y nuestro producto carecerá de ingredientes esenciales que hagan posible su éxito en el mercado.

El post “Lo que NO te van a enseñar en ese curso de Diseño de Producto” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Estrategias de crecimiento en mercados tecnológicos y Product Management de productos tecnológicos te pueden ayudar.]

Deja un comentario

No todos los experimentos tienen por objetivo contrastar aspectos muy relacionados con la naturaleza, funcionalidad y experiencia del producto (los prototipos funcionales son uno de ellos). También es imprescindible confirmar las dimensiones relacionadas con la viabilidad del negocio.

Damos fin a nuestra serie sobre el papel de la experimentación en el descubrimiento y validación de productos, en este caso con experimentos para contrastar la viabilidad del negocio y prototipos funcionales para confirmar con alta fidelidad todos los aspectos del producto.

Experimentos de viabilidad

En general, el propósito de un producto para la empresa es construir a su alrededor un negocio rentable y escalable. Y sobre eso versan las hipótesis de viabilidad. El éxito de un producto en el mercado no sólo depende (principalmente) de los clientes: también hay que validar su encaje con otros componentes de nuestro proceso de generación de beneficios: marca, generación de demanda, fuerza comercial (sobre el terreno y remota), distribuidores, partners, finanzas, legal, dirección general. Estos son aspectos que a muchos product managers les suelen resultar incómodos (sobre todo si provienen del ámbito técnico) pero son los que contribuyen a dar entidad a su puesto como el “mini-CEO del producto”.

Experimento viabilidadEn fase de descubrimiento los experimentos de viabilidad implican exponer a los implicados de la organización (marketing, ventas, soporte…) a prototipos de producto, para validar las hipótesis que les afectan. Es una forma de crítica interna. No se trata de una sesión tipo demo comercial (el product manager pilota) ni de test de usabilidad (el usuario pilota) sino una sesión interactiva en la que se da al interesado la oportunidad de explorar el producto e identificar cualquier aspecto que pudiera ser un problema en fase de comercialización (por supuesto, no se trata de ocultarles nada, sino todo lo contrario).

Con este enfoque, a continuación se citan algunos de los departamentos afectados y las hipótesis que habría que validar con ellos:

  • Marketing: ¿El producto es consistente con la promesa de nuestra marca (lo que la gente espera de nosotros)? ¿Sería posible construir programas y actividades eficaces y eficientes de generación de demanda para el producto? ¿Implicaría un gran cambio de canales y técnicas?
  • Ventas: ¿El producto requiere una relación personal cercana para su venta? ¿O puede gestionarse con un modelo de inside sales remoto? ¿El precio del producto justifica la inversión en fuerza de ventas? ¿La actual formación y capacidades de los vendedores son adecuadas? ¿O habría que formarlos o contratar nuevo personal?
  • Soporte: ¿El producto requiere un modelo de soporte muy cercano? ¿La actual formación y capacidades del personal de soporte son adecuadas?
  • Desarrollo de negocio: ¿El nuevo producto encaja en nuestras relaciones actuales con partners y distribuidores? ¿Van a poder y querer apoyar el producto? ¿Entra en competencia o conflicto con sus actividades?
  • Legal: ¿El producto tiene implicaciones en cuanto a privacidad, cumplimiento normativo, propiedad intelectual o competencia que puedan traer problemas legales?
  • Finanzas: ¿La estructura de costes del producto es suficiente para sustentar una operación rentable?

Prototipo funcional

En ocasiones necesitamos validar hipótesis en fase de descubrimiento que hacen necesario recoger algunos datos de uso real del producto. Y, por supuesto, lo necesitamos conseguir sin invertir el dinero ni el tiempo que se necesita para construir el producto real, escalable y vendible.

Un prototipo funcional es una implementación limitada del producto, acotada en cuanto a sus casos de uso, UX, funcionalidad y prestaciones. Y típicamente carece de toda la productización que se requiere para el producto final en términos de rendimiento, escalabilidad, pruebas automatizadas, instrumentación de analítica, internacionalización, localización, etc.

El prototipo funcional es sustancialmente más pequeño que el futuro producto (y construido a una fracción de su coste, típicamente 5-10%) y basta con que funcione suficientemente bien como para evaluarlo y recoger datos sobre un conjunto reducido de casos de uso con un conjunto limitado de usuarios.

A diferencia de otros prototipos, éste contiene código funcional que debe ser desarrollado por el departamento de Ingeniería/Desarrollo/Tecnología (no por los diseñadores). Esencialmente es similar a un piloto del producto, pero en el caso del prototipo la implementación es provisional y, en general, desechable.

El prototipo funcional es una técnica que se presta a análisis cualitativos y cuantitativos, y sirve para validar aspectos de deseabilidad, utilidad, usabilidad, comprabilidad, factibilidad y viabilidad.

El camino por delante: validación del producto

Una vez comprobado el encaje Problema-Solución deberíamos acelerar las actividades de Implementación o construcción del producto propiamente dicho, para llegar a algo que sea funcional, replicable, seguro, fiable, escalable, mantenible, soportable por la organización… y facturable. La validación termina cuando se comprueba el encaje Producto-Mercado: hemos llegado a una versión mínima del producto que los clientes valoran, compran y nos ayudan a mejorar con su feedback, y hemos identificado un proceso comercial repetible.

Ingeniería ágil

La mejor práctica para la Implementación en muchos escenarios consiste en aplicar técnicas de ingeniería ágil (por ejemplo, Scum o Kanban). En ellas el feedback del mercado es continuo, pero ya no con artefactos desechables sino con un producto real en continua evolución y mejora. Este feedback nos permite ir iterando y refinando el producto a lo largo de su construcción.

Como durante el descubrimiento, tenemos que seguir sometiendo al producto (ahora, real) a experimentos cualitativos que contrasten su deseabilidad, utilidad, usabilidad, comprabilidad, factibilidad y viabilidad. Pero en esta fase, gracias a la analítica de producto,  cobran mucha más importancia los experimentos cuantitativos basados no ya en lo que los clientes dicen, sino en su comportamiento real (lo que hacen).

Analítica de producto

Especialmente en productos digitales (software, contenidos), pero en general en cualquier tipo de producto o servicio habilitado por software (y cada vez son más, desde los electrodomésticos a los servicios de retail que mezclan online y offline) la tecnología permite realizar una monitorización exhaustiva del uso de ellos que hacen los clientes: cuándo lo usan, durante cuánto tiempo, qué funciones son las más utilizadas… Nunca había sido tan fácil saber exactamente cómo usan nuestro producto los clientes.

En “Analítica del funnel en negocios SaaS” describíamos cómo analizar la experiencia de cliente en negocios de software como servicio, pero lo que allí decíamos puede aplicarse fácilmente a negocios de otra índole, con tal de que su funnel comercial y su producto estén instrumentados para recoger los datos necesarios para realizar estos análisis.

Algunas técnicas y aspectos clave, muchos de los cuales hemos cubierto en posts anteriores:

  • Definición del funnel que mejor representa a nuestro producto (p. ej.: Awareness, Acquisition, Activation, Retention, Referral, Revenue) para estructurar el análisis.
  • La importancia de la retención de los clientes como motor del crecimiento: si no optimizamos la retención de nuestro producto estaremos acelerando un funnel con “escapes”. Métricas de abandono (churn).
  • Experimentos A/B y multivariable: donde se comparan diferentes alternativas de procesos y experiencias de cliente, para medir cuál se comporta mejor.
  • Análisis de cohortes: para analizar las diferencias entre grupos homogéneos de usuarios (p. ej., los que provienen de un mismo canal o se registraron el mismo mes).
  • Economías unitarias: CLTV (Customer Lifetime Value) y CAC (Customer Acquisition Cost).

Y con esto termina nuestra serie sobre la experimentación y su valor para el descubrimiento y validación de productos. Espero haber aportado una panorámica mínimamente descriptiva de los experimentos más habituales. Pero recordad: la idoneidad de uno u otro para vuestro caso depende de cuáles sean las incertidumbres más importantes para vuestro negocio y de cuál es la mejor manera para eliminarlas.

El post “Experimenta para descubrir y validar tu producto (4)” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Estrategias de crecimiento en mercados tecnológicos y Product Management de productos tecnológicos te pueden ayudar.]

Deja un comentario