Customer Success y alineación con Producto

Casi todos los equipos de CS tienen alguna versión de ambos: un conjunto de conversaciones con advisory board donde clientes senior aportan sobre la dirección estratégica, y una práctica más informal de involucrar a clientes cuando se construye algo nuevo. El problema es que muy pocos equipos trazan una línea clara entre ambos. Un cliente que participó en el advisory board del trimestre anterior se integra a una revisión de prototipo porque está comprometido. Un PM que quiere retroalimentación de diseño programa una "sesión de advisory" con cinco cuentas y les muestra un mockup en Figma. El vocabulario se confunde, las expectativas se confunden, y los resultados también.

La distinción es operativa, no filosófica. Los customer councils y advisory boards tratan sobre la dirección estratégica. Involucran a un grupo más amplio de clientes, se realizan con cadencia trimestral y producen insumos sobre hacia dónde debe ir el producto en los próximos 12-18 meses. El codiseño se centra en una funcionalidad específica. Involucra entre 3 y 6 cuentas, se desarrolla durante 4-8 semanas y produce insumos directos sobre cómo debe funcionar esa funcionalidad a nivel de construcción. El compromiso de tiempo, la expectativa del cliente, el formato de la sesión y lo que se considera éxito son completamente distintos.

Confundirlos crea dos modos de falla. El advisory board se posiciona como si tuviera una influencia en el codiseño que en realidad no tiene, generando deuda de expectativas cuando la hoja de ruta toma direcciones que los participantes no aprobaron. El compromiso de codiseño se infla hasta convertirse en una conversación estratégica, abarcando territorios que ninguna funcionalidad individual puede satisfacer. Ambas fallas consumen capital relacional, y ambas son prevenibles con disciplina operativa.

Este artículo trata sobre cómo ejecutar el codiseño. El artículo 11 cubre los advisory boards. La línea entre ambos es lo que este artículo comienza por trazar con claridad.

El Modelo de Operaciones de Codiseño con Clientes definido aquí es explícitamente distinto de los customer advisory boards (artículo 11 de esta colección), que abordan la dirección estratégica con un grupo más amplio en una cadencia trimestral. El codiseño es operativo, no estratégico: moldea una funcionalidad específica en el pipeline de construcción con 3-6 cuentas durante 4-8 semanas. El modelo tiene cuatro disciplinas operativas: (1) disciplina de alcance: el codiseño cubre una funcionalidad, no una dirección de producto; (2) disciplina de cohorte: 3-6 cuentas que representan la versión más aguda del problema, no las más leales ni las más grandes; (3) disciplina de roles: Producto lidera la decisión de construcción, CS facilita la sesión, Ingeniería observa; (4) disciplina de expectativas: los clientes codiseñan el qué, los ingenieros son propietarios del cómo, Producto toma la decisión final. Cada falla de codiseño se remonta al incumplimiento de una de estas cuatro disciplinas.

Advisory Board vs. Codiseño: La Distinción Necesaria

La investigación de McKinsey sobre la construcción de organizaciones B2B centradas en el cliente muestra que las empresas que confunden los aportes estratégicos del advisory con el codiseño de funcionalidades específicas terminan con datos de clientes que no responden ni a la pregunta estratégica ni a la pregunta de construcción con precisión. La distinción es operativa, no filosófica, y la confusión es lo suficientemente común como para merecer una aclaración precisa.

Los customer advisory boards reúnen a un grupo más amplio, típicamente entre 8 y 15 representantes senior del cliente, para brindar aportes sobre la dirección estratégica. Las preguntas son: ¿hacia dónde debería ir el producto en el próximo año? ¿Qué problemas anticipa que aún no estamos resolviendo? ¿En qué tienen ventajas nuestros competidores que usted querría que cerremos? Los advisory boards son prospectivos y amplios. No moldean funcionalidades individuales. Moldean la visión del producto que impulsa la hoja de ruta. La cadencia es trimestral. El resultado es contexto estratégico para el equipo de PM.

El codiseño reúne a una pequeña cohorte (3-6 cuentas) para brindar aportes operativos sobre una funcionalidad específica que ya está en el pipeline de construcción. Las preguntas son: ¿este flujo de trabajo coincide con cómo realiza realmente esta tarea? ¿En qué punto de este flujo se encuentra con un problema? ¿Qué haría que esto sea lo suficientemente útil como para cambiar la forma en que trabaja su equipo? El codiseño es presente y específico. Moldea una funcionalidad concreta que se está construyendo ahora. La cadencia es intensiva durante un compromiso corto. El resultado es retroalimentación accionable a nivel de construcción.

Cuándo se necesita codiseño vs. cuándo es suficiente el aporte del advisory. Si la pregunta es "¿deberíamos construir esta categoría de capacidad?", el aporte del advisory es suficiente. Si la pregunta es "¿esta implementación específica de esa capacidad es algo que nuestros usuarios objetivo pueden realmente usar?", se necesita codiseño. El aporte del advisory le dice si está construyendo en la dirección correcta. El codiseño le dice si lo que está construyendo realmente funcionará.

La decisión práctica: el codiseño está justificado cuando hay suficiente ambigüedad de diseño en una funcionalidad específica que equivocarse significaría reconstruir partes significativas después del lanzamiento, y cuando se tienen clientes que tienen el caso de uso específico y la experiencia de dominio para evaluar una solución propuesta.

Datos Clave: Resultados de los Programas de Codiseño

Las funcionalidades desarrolladas con sesiones estructuradas de codiseño con clientes tienen tasas de adopción un 41% más altas a los 90 días post-GA en comparación con las funcionalidades desarrolladas solo con aporte del advisory (Pendo, 2024).

Las sesiones de codiseño facilitadas por el PM producen un 35% menos de retroalimentación crítica que las facilitadas por CS, porque los participantes suavizan las críticas cuando la persona que construyó lo que están evaluando está en la sala (UserTesting, 2024).

Los compromisos de codiseño que terminan sin una sesión formal de cierre tienen tasas 2,1 veces más altas de insatisfacción reportada por los participantes al lanzamiento del GA, en comparación con los compromisos que incluyen una llamada de debrief estructurada (Gainsight, 2024).

Quién Se Invita al Codiseño (y Quién No)

Los criterios de selección son más específicos que para un programa beta o un advisory board, y el costo de equivocarse es mayor. Una selección deficiente para el advisory board produce aportes estratégicos vagos. Una selección deficiente para el codiseño produce decisiones de construcción basadas en el caso de uso equivocado.

"Las funcionalidades desarrolladas con sesiones estructuradas de codiseño con clientes tienen tasas de adopción un 41% más altas a los 90 días post-GA en comparación con las funcionalidades desarrolladas solo con aporte del advisory." (Pendo, 2024)

El filtro de agudeza del problema. El primer criterio: ¿esta cuenta tiene el problema específico que la funcionalidad está siendo construida para resolver, y lo tiene con suficiente agudeza como para dar retroalimentación significativa sobre una solución propuesta? No "¿encuentran la categoría general del problema?" sino "¿es este problema una limitación operativa real para ellos ahora mismo?" Las cuentas que tienen el problema teóricamente ("podríamos tener este problema si nuestro equipo creciera") no pueden evaluar una solución con la misma especificidad que las cuentas que lo tienen operativamente, todos los días.

La barrera del estado de salud de CS. Solo puntuaciones de salud verde o amarilla. El codiseño con cuentas en rojo es extracción, no colaboración. Un cliente que gestiona una crisis de soporte activa, un conflicto presupuestario o una implementación estancada no tiene la capacidad mental para dar retroalimentación de producto honesta. Está gestionando su propia situación. Y si la experiencia de codiseño es frustrante (lo cual suele ocurrir en trabajo de etapas tempranas de funcionalidades), agrava una relación ya bajo estrés. El glosario de alineación CS & Product define los niveles de puntuación de salud y el vocabulario compartido que CS y Producto necesitan para aplicar esta barrera de forma consistente.

El filtro de capacidad. ¿Este cliente tiene la experiencia de dominio para evaluar si una solución propuesta realmente resuelve el problema? Un cliente que tiene el problema pero no tiene la sofisticación técnica u operativa para distinguir "este flujo de trabajo no encaja con nuestro proceso" de "este flujo de trabajo es confuso" es un colaborador de codiseño limitado. Se necesitan cuentas donde el profesional que asiste a la sesión pueda explicar exactamente cómo hacen actualmente la tarea que la funcionalidad reemplazará, porque esa comprensión es lo que hace que su retroalimentación sobre la solución propuesta sea precisa en lugar de impresionista.

El límite de la cohorte. Entre 3 y 6 cuentas. Esta no es una directriz flexible. Es la realidad operativa de lo que un PM puede gestionar y con lo que un CSM puede trabajar de forma significativa durante un compromiso de 4-8 semanas. Seis ya es ambicioso. Ocho se convierte en un comité. Con 10, se está ejecutando una beta, no un compromiso de codiseño, y se ha perdido la intimidad que hace que la retroalimentación del codiseño sea diferente de los datos de una encuesta.

El encuadre de la invitación importa tanto como la selección. "Ayúdenos a construir esto bien" es el encuadre correcto. "Denos su lista de deseos" es el equivocado. La invitación debe ser específica sobre el alcance de la funcionalidad, explícita sobre el compromiso de tiempo (típicamente 3-5 sesiones durante 4-8 semanas, cada una de 60-90 minutos), clara en que se trata de aporte de diseño y no de influencia en la hoja de ruta, y honesta en que la decisión de construcción final corresponde a Producto, no a la cohorte de codiseño. Con la cohorte correcta en su lugar, la estructura del compromiso determina si las sesiones producen señales reales.

Estructurar el Compromiso de Codiseño

Un compromiso de codiseño que se extiende más de 8 semanas generalmente indica expansión de alcance. Un compromiso de codiseño con más de 5 sesiones generalmente indica que el problema no estaba suficientemente bien definido desde el principio. La estructura a continuación se aplica a un compromiso bien delimitado.

Trabajo previo: Producto comparte el planteamiento del problema y las restricciones. Antes de la primera sesión, los participantes reciben un brief escrito del PM: el problema que se está resolviendo, por qué se eligió el enfoque propuesto y qué restricciones son innegociables (limitaciones técnicas, requisitos regulatorios, decisiones de arquitectura existentes). Los clientes no codiseñan en el vacío. Necesitan contexto sobre lo que es posible antes de poder dar aportes significativos sobre lo que es mejor.

Sesión 1: Validación del problema. El propósito de esta sesión no es mostrarle al cliente una solución. Es validar que la comprensión de Producto sobre el problema coincide con la experiencia vivida del cliente. El PM presenta el planteamiento del problema. El cliente reacciona: "¿esto describe con precisión lo que está enfrentando?" Las discrepancias aquí (y casi siempre las hay) son el resultado más valioso de todo el compromiso. Surgen antes de que cualquier trabajo de construcción esté bloqueado.

Sesión 2: Retroalimentación sobre el prototipo. El PM presenta un prototipo inicial o un mockup del flujo de trabajo. La tarea del cliente: recorrerlo como lo usaría en la práctica, narrando sus reacciones. No "¿le gusta esto?" sino "explíqueme qué haría a continuación." El CSM captura los puntos de fricción, los momentos de confusión y las soluciones alternativas que el cliente sugiere espontáneamente. Ingeniería observa y toma notas pero no presenta, defiende ni explica nada. Está ahí para escuchar directamente, no para justificar decisiones.

Sesión 3: Iteración de la solución. El PM presenta el prototipo revisado incorporando los comentarios de la sesión 2. El propósito: confirmar que los cambios abordaron la fricción, identificar nuevos problemas introducidos por los cambios y comenzar a converger hacia un diseño que funcione. Esta sesión es típicamente más corta que la sesión 2. Si la iteración fue buena, hay menos que cuestionar.

Sesiones 4-5 (si es necesario): Aprobación final y casos límite. Estas sesiones son para los participantes que tienen casos de uso lo suficientemente complejos como para que las sesiones 1-3 no hayan resuelto completamente cómo funciona la funcionalidad para ellos. No todas las cohortes necesitan las sesiones 4-5. Si un compromiso de tres sesiones produce señales lo suficientemente claras como para finalizar el diseño, agregar sesiones por la estructura misma desperdicia el tiempo de los participantes y arriesga erosionar la buena voluntad sobre la que se construye el programa.

Reglas de asistencia. El trabajo del MIT Media Lab sobre el codiseño tecnológico comunitario confirma que el valor del codiseño proviene específicamente de la "co" (la estructura de participación en sí misma, no solo de los resultados), razón por la que el modelo de asistencia del proveedor aquí separa los roles en lugar de colapsarlos en una única presencia del equipo de producto. Del proveedor: el PM lidera, el CSM facilita, Ingeniería observa. El PM está ahí para escuchar el caso de uso y tomar decisiones de construcción en tiempo real sobre qué retroalimentación incorporar. El CSM está ahí para gestionar la dinámica de la sesión: sacar a los participantes callados, redirigir a los participantes que están rediseñando todo el producto en lugar de la funcionalidad específica, y capturar señales relacionales que el PM podría perderse. Ingeniería está ahí para escuchar el caso de uso en el lenguaje del cliente, no para presentar restricciones técnicas ni defender decisiones de implementación.

Del cliente: el profesional que vive el problema todos los días, no el patrocinador ejecutivo. Un ejecutivo que se entera del problema a través de su equipo es un defensor estratégico útil. Es un participante deficiente en el codiseño porque no tiene la especificidad operativa para evaluar si una solución propuesta funciona a nivel de flujo de trabajo. El asistente correcto puede decir "cuando hago esta tarea, la hago de esta manera, y el flujo propuesto falla en el paso tres debido a X."

El Rol de CS en las Sesiones de Codiseño

"Las sesiones de codiseño facilitadas por el PM producen un 35% menos de retroalimentación crítica que las facilitadas por CS, porque los participantes suavizan las críticas cuando la persona que construyó lo que están evaluando está en la sala." (UserTesting, 2024)

CS facilita; CS no aboga. Esta es la línea más difícil de mantener. El trabajo del CSM en una sesión de codiseño no es hacer que el cliente se sienta bien con el producto o proteger la relación de la retroalimentación crítica. Es identificar señales honestas: hacer preguntas de seguimiento cuando la retroalimentación del cliente es vaga, sacar a la luz la insatisfacción que el cliente está expresando de forma educada en lugar de directa, y no suavizar la transcripción.

Gestionar al participante dominante. Casi todas las cohortes de codiseño tienen uno: el cliente que está comprometido, es articulado y es ruidoso, y cuyas opiniones silencian a los demás participantes. El trabajo de facilitación del CSM es redistribuir activamente el tiempo al micrófono: "Hemos escuchado mucho de [cuenta A] sobre esto. [Cuenta B], ¿cómo encaja esto con el flujo de trabajo de su equipo?" La voz más ruidosa en una sesión de codiseño rara vez es la más representativa.

Capturar la retroalimentación en formato de salida estructurado. El entregable de cada sesión no es una transcripción ni un resumen. Es un registro de retroalimentación estructurado al que Producto puede hacer referencia directamente cuando toma decisiones de construcción. Formato: punto de fricción (específico, con contexto de flujo de trabajo) / qué cuenta lo planteó / gravedad (bloqueante / significativo / menor) / solución sugerida por el cliente (si se ofreció) / lectura inicial del PM (incorporar / rechazar / investigar más). Este formato se acuerda antes de que comience el compromiso. Los CSM no lo improvisan sesión por sesión. El playbook de captura sistemática de retroalimentación proporciona la taxonomía completa para traducir las notas de las sesiones en registros listos para el backlog.

Señalar la expansión de alcance en tiempo real. Cuando un participante empieza a diseñar todo el producto en lugar de la funcionalidad específica ("mientras hablamos de esto, ¿qué pasaría si también reconstruyeran la forma en que funciona todo el panel?"), el CSM redirige: "Ese es un aporte más amplio muy valioso, y lo captaremos por separado. Para la sesión de hoy, queremos mantenernos enfocados en [alcance específico de la funcionalidad] para poder profundizar lo suficiente como para ser útiles." Esa redirección es responsabilidad del CSM, no del PM. La presencia del PM en la sala hace que sea más difícil que redirija sin parecer defensivo.

Las Condiciones Innegociables de Producto en el Codiseño

La decisión de construcción corresponde a Producto. Siempre. El codiseño es un insumo sobre cómo se construye una funcionalidad, no una delegación de la decisión de construcción a un comité de clientes. Esto debe establecerse en el encuadre de la inscripción y reforzarse al inicio de cada sesión. "Queremos su perspectiva sobre si este enfoque funciona para su flujo de trabajo. La decisión final sobre lo que construimos es nuestra, y seremos honestos con ustedes sobre qué insumos estamos incorporando y por qué."

Las restricciones técnicas son innegociables y deben establecerse desde el principio. Las sesiones de codiseño donde los participantes diseñan su solución ideal y el PM luego tiene que explicar por qué nada de ello es técnicamente posible son un desperdicio del tiempo de todos y crean deuda de expectativas. Antes de la sesión 1, el brief escrito debe indicar claramente: "Esto es lo que está técnicamente fijo en este diseño. Esto es donde tienen influencia genuina." Los clientes que entienden el espacio de restricciones diseñan dentro de él. Los que no lo entienden diseñan alrededor de él, produciendo retroalimentación que no es accionable.

Los clientes codiseñan el qué; los ingenieros y los PM son propietarios del cómo. Un participante puede decir "necesito poder reasignar la propiedad de una tarea en masa sin perder el registro de auditoría." Eso es el qué. Cómo se implementa técnicamente (qué modelo de datos, qué patrón de API, qué componente de interfaz) es una decisión de ingeniería. La línea entre qué y cómo es donde vive la disciplina de alcance.

Cuando los participantes del codiseño están en desacuerdo entre sí. Ocurre en casi todos los compromisos de múltiples cuentas, porque las cuentas tienen flujos de trabajo diferentes, restricciones diferentes y definiciones diferentes de "obvio." Producto arbitra. No promediando el desacuerdo ("haremos una versión que satisfaga parcialmente a ambos") sino tomando una decisión explícita: "Hemos escuchado dos modelos de flujo de trabajo diferentes aquí. Vamos a construir para el modelo de [Cuenta A] porque se corresponde más estrechamente con nuestro ICP principal. Para [Cuenta B], aquí le sugerimos cómo adaptar su flujo de trabajo a la funcionalidad." El arbitraje transparente es mejor que pretender que el desacuerdo no existe.

Gestión de Expectativas Durante Todo el Proceso

El riesgo de expectativas en el codiseño es diferente al del advisory board. Los participantes del advisory board esperan influencia estratégica. Los participantes del codiseño esperan que su flujo de trabajo específico se refleje en lo que se lanza. Cuando la funcionalidad final no se parece exactamente a lo que diseñaron, los participantes sienten que el codiseño fue un teatro en lugar de una colaboración genuina.

En la sesión 1, establezca el modelo de forma explícita. "Están aquí porque tienen la versión más aguda del problema que estamos resolviendo y la experiencia de dominio para decirnos si nuestra solución propuesta realmente funciona. Su aporte informará directamente lo que construimos. Pero no son el único insumo. También estamos trabajando dentro de restricciones técnicas, equilibrando múltiples casos de uso y tomando decisiones de producto que pueden no reflejar completamente la preferencia de ninguna cuenta individual. Seremos transparentes con ustedes sobre qué estamos incorporando y qué no, y por qué."

Cómo manejar a un participante cuyas ideas no se incorporaron. El CSM toma la iniciativa de forma proactiva, antes de que se lance la funcionalidad. "Discutimos [aporte específico] en la sesión 3. En última instancia, decidimos no implementarlo en este lanzamiento porque [razón específica]. Quiero que lo sepan directamente, antes de que vean la funcionalidad en el GA." Esa conversación, realizada antes de que el participante descubra la brecha por sí mismo, es un acto que preserva la relación. Realizada después, parece control de daños.

La llamada de debrief no es opcional. La investigación de HBR sobre cómo obtener retroalimentación honesta de los clientes establece que el cierre de un compromiso de retroalimentación es donde la confianza se confirma o se rompe. Los clientes necesitan ver que su aporte fue tomado en serio, no solo procesado. Cada compromiso de codiseño termina con una llamada de debrief de 30 minutos donde el PM lleva a los participantes del codiseño por: qué entró en la construcción, qué no, y por qué. Este es el cierre formal del compromiso. Los participantes que no reciben un debrief (que experimentan el compromiso como "dimos nuestro tiempo y luego la funcionalidad simplemente se lanzó") son la fuente del problema de reputación del codiseño que dificulta el reclutamiento futuro.

Cuando el Codiseño Falla

Tres modos de falla cubren la mayor parte de lo que sale mal, y cada uno tiene una solución específica.

Expansión de alcance: los clientes diseñan todo el producto. La sesión ha derivado de la funcionalidad específica hacia una conversación sobre toda la experiencia del producto. Causa: el encuadre de la invitación fue demasiado amplio ("ayúdenos a mejorar el producto"), el CSM no redirigió con suficiente anticipación, o el PM comenzó a hacer preguntas que abrieron un alcance más amplio ("¿y qué más haría que esta categoría de trabajo sea mejor para usted?"). Solución: reestablezca el alcance al inicio de cada sesión, capacite al CSM para redirigir visiblemente y sin disculpas, y mantenga las preguntas del PM estrechamente ligadas a la funcionalidad que se está codiseñando.

Captura relacional: el PM dice que sí a todo. El PM está tan enfocado en mantener una relación positiva con el participante que señala acuerdo con insumos que no tiene intención de implementar, para evitar conflictos en la sala. Esto produce dos problemas: participantes que se sienten validados durante las sesiones y traicionados en el GA, y un registro de retroalimentación que sobrerrepresenta compromisos que no existen. Solución: el CSM (no el PM) gestiona el tono de la sesión. El trabajo del PM es escuchar y registrar, no responder afirmativamente a cada sugerencia. El formato de salida estructurado (incorporar / rechazar / investigar) fuerza un reconocimiento explícito de qué insumos se están actuando y cuáles no.

Sesgo de cohorte: los participantes no son representativos del ICP más amplio. La cohorte de codiseño se seleccionó porque estaban disponibles y comprometidos, no porque representen el caso de uso objetivo. La retroalimentación refleja su flujo de trabajo específico, que es un caso límite, no el caso de uso central. Las funcionalidades construidas con esa especificación funcionan bien para los participantes del codiseño y mal para la base general de clientes. Solución: aplique el filtro de agudeza del problema de forma estricta en la selección. Si las cuentas que tienen el problema más agudamente no están lo suficientemente sanas o disponibles para participar, retrase el codiseño hasta que se puedan identificar mejores candidatos. No sustituya con participantes que cumplen mejor los criterios relacionales que los de caso de uso.

Después del Codiseño: Cerrar el Compromiso

Reconocimiento al participante sin prometer demasiado acceso futuro. Los participantes del codiseño invirtieron tiempo y confianza. El cierre del compromiso debe reconocer eso de forma específica: "Nos dedicaron [N sesiones / N horas] durante [N semanas]. [Las características específicas de lo que se lanzó] reflejan directamente lo que nos dijeron. Gracias." Ese es el nivel correcto de reconocimiento. Prometer demasiado ("nos aseguraremos de que ustedes sean la primera cuenta a la que acudamos para la próxima funcionalidad en esta área") crea deuda de inscripción en el próximo programa de codiseño antes de que siquiera comience.

Los participantes del codiseño ven la funcionalidad final antes del GA. Esto es innegociable. Los participantes que participaron en 4 sesiones y luego ven el anuncio del GA al mismo tiempo que cualquier otro cliente sienten que su aporte fue absorbido, no honrado. La secuencia: el PM comparte la funcionalidad final con los participantes del codiseño 1-2 semanas antes del GA. Los participantes tienen la oportunidad de señalar cualquier problema crítico que se haya pasado por alto. Luego se lanza para todos. La estructura de la llamada de debrief, el resumen escrito y el plazo de 48 horas se describen en el artículo sobre cierre del ciclo de retroalimentación con clientes. Esa cadencia se aplica aquí exactamente de la misma manera que para los programas beta y de advisory.

Retrospectiva antes del próximo codiseño. El debrief del compromiso no es solo para los participantes. Es para el equipo interno. ¿Qué produjo el formato de la sesión que fue útil? ¿Qué formato de retroalimentación funcionó? ¿Se seleccionaron las cuentas correctas? ¿Qué cambiaríamos en el encuadre de la invitación? Una retrospectiva interna de 60 minutos después de cada compromiso de codiseño mejora la calidad del siguiente y reduce la tasa de fallos con el tiempo.

Consideraciones para el Mercado Medio

El codiseño consume recursos. Una empresa de mercado medio sin una función de investigación de UX dedicada aún puede ejecutarlo, pero necesita adecuar las expectativas. La versión mínima viable: un PM, un CSM, tres cuentas, tres sesiones, sin necesidad de prototipo en Figma. Un mockup inicial del flujo de trabajo descrito en lenguaje sencillo funciona. El PM lee la salida estructurada, el CSM facilita, y el resultado es lo suficientemente específico como para informar la construcción.

"Los compromisos de codiseño que terminan sin una sesión formal de cierre tienen tasas 2,1 veces más altas de insatisfacción reportada por los participantes al lanzamiento del GA, en comparación con los compromisos que incluyen una llamada de debrief estructurada." (Gainsight, 2024)

Lo que no puede simplificarse: la llamada de debrief, los criterios de selección por agudeza del problema y el establecimiento explícito de expectativas en la sesión 1. Esos son los elementos fundamentales. Todo lo demás puede simplificarse. El seguimiento de qué participantes del codiseño están listos para la activación después del GA es donde la identificación de barreras de adopción entra en juego. El equipo de codiseño ya conoce los puntos de fricción; el equipo post-venta necesita ese conocimiento para acelerar la activación para la base más amplia.

Análisis de Rework: Los programas de codiseño son operativamente ligeros (3-6 cuentas, 3-5 sesiones, 4-8 semanas) pero requieren un seguimiento riguroso de los resultados de las sesiones, las puntuaciones de salud de los participantes y las resoluciones de retroalimentación en múltiples conversaciones simultáneas. Los equipos de CS de mercado medio que ejecutan codiseño en Rework pueden usar el seguimiento de tareas a nivel de proyecto para gestionar la estructura de las sesiones, vincular los registros de retroalimentación al estado de salud de la cuenta e identificar el filtro de agudeza del problema junto con los datos de ICP sin necesidad de construir un sistema separado de gestión de investigación. El formato de retroalimentación estructurado (punto de fricción / gravedad / resolución del PM) se corresponde directamente con el modelo de tareas y comentarios de Rework.

Preguntas Frecuentes

¿Qué es el Modelo de Operaciones de Codiseño con Clientes?

El Modelo de Operaciones de Codiseño con Clientes es la estructura operativa para ejecutar el codiseño de funcionalidades con entre 3 y 6 clientes seleccionados durante 4-8 semanas. Es explícitamente distinto de los customer advisory boards, que brindan dirección estratégica a un grupo más amplio de forma trimestral. El codiseño moldea una funcionalidad específica en el pipeline de construcción. El modelo opera sobre cuatro disciplinas: alcance (una funcionalidad, no una dirección de producto), cohorte (selección por agudeza del problema, no por lealtad), roles (CS facilita, Producto lidera la decisión de construcción, Ingeniería observa) y expectativas (los clientes codiseñan el qué, los ingenieros son propietarios del cómo).

¿En qué se diferencia el codiseño de un customer advisory board?

Los advisory boards reúnen a entre 8 y 15 clientes senior trimestralmente para brindar aportes sobre la dirección estratégica: hacia dónde debería ir el producto en los próximos 12-18 meses. El codiseño reúne entre 3 y 6 cuentas durante 4-8 semanas para proporcionar retroalimentación a nivel de construcción sobre una funcionalidad específica que ya está en el pipeline. Los aportes del advisory responden "¿deberíamos construir esta categoría de capacidad?" El codiseño responde "¿esta implementación específica realmente funcionará para nuestros usuarios objetivo?" Confundirlos produce fatiga en el advisory y expansión de alcance en el codiseño.

¿Quiénes deberían ser invitados a las sesiones de codiseño?

Los criterios de selección tienen tres barreras: (1) agudeza del problema: la cuenta tiene el problema específico que la funcionalidad está resolviendo, operativa y agudamente, no teóricamente; (2) puntuación de salud: verde o amarilla únicamente; las cuentas rojas están gestionando su propia situación y no pueden evaluar una nueva funcionalidad de forma objetiva; (3) capacidad: el profesional que asiste puede describir exactamente cómo realizan actualmente la tarea que la funcionalidad reemplazará, porque esa especificidad operativa es lo que hace que su retroalimentación sea precisa en lugar de impresionista. El límite de la cohorte es de 6 cuentas. Por encima de eso, se está ejecutando una beta, no un compromiso de codiseño.

¿Por qué CS debe facilitar las sesiones de codiseño y no Producto?

Las sesiones de codiseño facilitadas por el PM producen un 35% menos de retroalimentación crítica que las facilitadas por CS, porque los participantes suavizan las críticas cuando la persona que construyó lo que están evaluando está en la sala (UserTesting, 2024). Los facilitadores de CS crean separación entre la capa relacional y la capa de evaluación. El trabajo del CSM es sacar a la luz la insatisfacción que los participantes expresan de forma educada, redirigir la expansión de alcance en tiempo real y capturar el registro de retroalimentación estructurado, sin suavizar la transcripción. El PM observa y toma decisiones de construcción en tiempo real; Ingeniería observa y escucha el caso de uso en el lenguaje del cliente.

¿Qué pasa cuando los participantes del codiseño están en desacuerdo entre sí?

Producto arbitra. No promediando el desacuerdo ni pretendiendo que no existe, sino tomando una decisión explícita: "Hemos escuchado dos modelos de flujo de trabajo diferentes. Vamos a construir para el modelo de la Cuenta A porque se corresponde más estrechamente con nuestro ICP principal. Para la Cuenta B, aquí le sugerimos cómo adaptar su flujo de trabajo a la funcionalidad." El arbitraje transparente es mejor para la relación que el compromiso vago. Los participantes que entienden por qué no se eligió su modelo respetan la decisión. Los participantes que reciben una solución a medias y descubren después que no encaja con ninguno de los dos flujos de trabajo se sienten engañados.

¿Qué debe incluir la llamada de debrief del codiseño?

La llamada de debrief es una sesión de 30 minutos con el PM y el CSM presentes, realizada con los participantes del codiseño antes del GA. Cubre: qué entró en la construcción, qué no, y por qué. Los compromisos de codiseño que terminan sin una sesión formal de cierre tienen tasas 2,1 veces más altas de insatisfacción reportada por los participantes al lanzamiento del GA (Gainsight, 2024). Un resumen escrito sigue en un plazo de 48 horas. Los participantes que contribuyeron con 4 sesiones y reciben un debrief se sienten genuinamente consultados. Los que ven el anuncio del GA al mismo tiempo que cualquier otro cliente se sienten extraídos.

¿Cuánto tiempo debe durar un compromiso de codiseño?

Un compromiso de codiseño bien delimitado se desarrolla durante 3-5 sesiones a lo largo de 4-8 semanas. Los compromisos que se extienden más allá de las 8 semanas generalmente indican que el problema no estaba suficientemente bien definido desde el principio, o que el alcance se amplió a un territorio que ninguna funcionalidad individual puede satisfacer. Los programas con más de 5 sesiones muestran una calidad de sesión en declive debido a la fatiga de los participantes en el 73% de los casos de mercado medio (ProductLed, 2024). La llamada de debrief es obligatoria. Todo lo demás puede simplificarse para equipos más pequeños. Pero el debrief y los criterios de selección por agudeza del problema son los elementos fundamentales del modelo.

Más Información

Tara Minh

Senior Operations & Growth Strategist