POCs que predicen el éxito, y POCs que hacen perder el tiempo de todos

Un proof of concept debería responder una pregunta: ¿resolverá este producto nuestro problema específico en nuestro entorno específico? En la práctica, la mayoría de los POCs B2B responden una pregunta diferente: ¿puede el ingeniero de ventas de este proveedor hacer una buena demo con nuestro logo en ella?

La brecha entre un POC útil y uno teatral es enorme. Los compradores que no pueden distinguir la diferencia están tomando decisiones costosas con datos deficientes. Descubren seis meses después de firmar el contrato que la complejidad de integración que todos ignoraron durante la evaluación es ahora un proyecto de IT de seis semanas que nadie presupuestó.

Esto no es un problema de ética del proveedor. Los proveedores construyen POCs para ganar, no para descubrir los modos de fallo. La responsabilidad de diseñar una evaluación que genere señales reales recae en el comprador. La investigación de Harvard Business Review sobre las decisiones de compra B2B ha señalado durante mucho tiempo que los compradores que definen los criterios de evaluación por adelantado alcanzan mejores resultados a largo plazo que los que dependen de las demostraciones guiadas por el proveedor.

Cinco señales de que su POC es teatro

Antes de diseñar un mejor proceso, reconozca cómo se ve un POC teatral. Estos patrones son lo suficientemente comunes como para que la mayoría de los compradores encuentre al menos dos o tres en cualquier evaluación importante.

Datos controlados por el proveedor. El POC corre completamente con los datos de muestra del proveedor o una versión sanitizada de los suyos que el proveedor preparó. Sus datos reales, con sus casos extremos, inconsistencias históricas y nombres de campos no estándar, nunca tocan el sistema. La demo parece limpia porque los datos fueron curados para la demo.

Sin criterios de éxito escritos. Todos acuerdan antes del POC que están evaluando la "facilidad de uso" y la "capacidad de integración". Nadie escribe qué significa eso. Al final de seis semanas, el proveedor pregunta cómo fue y el champion dice "bastante bien", pero procurement e IT tenían expectativas completamente diferentes que nunca se plantearon.

El proveedor dirige todas las sesiones. Un POC útil involucra a su equipo usando realmente el producto. Un POC teatral involucra al ingeniero de ventas del proveedor demostrando el producto a su equipo todos los martes. Si sus usuarios no han hecho el trabajo ellos mismos, no han evaluado la usabilidad. Han evaluado la capacidad del proveedor para presentar.

Expansión del alcance sin ajuste del cronograma. El POC comienza como una evaluación de migración de CRM. En la semana tres, el proveedor ha propuesto también evaluar su módulo de automatización de marketing, porque "ya está configurado y le mostrará el valor completo de la plataforma". El alcance se ha duplicado. El cronograma no ha cambiado. La profundidad de evaluación del alcance original se ha reducido a la mitad.

Sin discusión sobre cómo se ve el fracaso. Un POC bien diseñado define, de antemano, qué resultado haría que usted no compre. Si todos están operando como si la compra fuera el único resultado posible, no está ejecutando una evaluación. Está ejecutando un cierre coreografiado.

Lo que un POC útil necesita definir de antemano

El único predictor más grande de la calidad del POC es si el comprador escribió un brief de diseño de POC antes de la primera sesión de kick-off con el proveedor. La mayoría no lo hace. Aquí está lo que ese brief necesita contener.

Criterios de éxito escritos. No "queremos ver si es fácil de usar". Los criterios escritos se ven así: "Onboarding de usuarios: el 80% de los usuarios piloto completan su primer flujo de trabajo central sin intervención de soporte dentro de 5 días hábiles". O: "Integración CRM: todos los cambios de etapa de deal en el CRM fuente se reflejan en esta plataforma dentro de 15 minutos, validado durante un período de observación de 10 días". Estos son falsificables. Pasan o fallan. No necesita debatir si pasaron.

Datos reales, no datos de demo. Sus datos reales son su mejor prueba de estrés. Si el proveedor necesita tiempo para entender su estructura de datos antes de que comience el POC, está bien, pero el POC en sí mismo debe ejecutarse con muestras representativas de sus datos reales, incluidas las partes más desordenadas. Cualquier problema de integración que surja durante este proceso habría surgido después del contrato de todas formas. Es mejor encontrarlo en la semana dos que en la semana diez después del go-live. La guía de limpieza y deduplicación de datos es un ejercicio útil previo al POC: los datos limpios revelan problemas reales de integración más rápido de lo que los datos desordenados los ocultan.

Definición del alcance de integración. Antes de que comience el POC, liste cada sistema al que esta herramienta necesita conectarse. No "tal vez algún día". Liste solo las integraciones requeridas para que el caso de uso base funcione. Para cada integración, defina quién la posee (IT, el proveedor o compartida) y cuál es el criterio de aceptación. Esto descubre la complejidad de integración oculta que mata los deals (y las implementaciones) más tarde.

Un cronograma de decisión. El POC tiene una fecha de finalización, y esa fecha de finalización es cuando el comité de compra se reúne nuevamente para tomar una decisión basada en los resultados del POC. No una "llamada de debrief" para planificar los próximos pasos. Una reunión de decisión. Si la reunión se posterga, el POC se extiende en consecuencia, pero la expectativa de que una decisión sigue a la evaluación se establece desde el inicio.

Roles y responsabilidades. ¿Quién de su lado posee el POC? ¿Quién es el contacto principal del proveedor? ¿Quién en su equipo es responsable de ejecutar los flujos de trabajo piloto? Esto importa porque los POCs fallan operativamente cuando nadie en el lado comprador tiene propiedad clara y la evaluación avanza en segundo plano mientras el trabajo real de todos sigue moviéndose.

El problema de los incentivos del proveedor

Aquí hay algo que la mayoría de las guías de compra no dicen directamente: su proveedor quiere que el POC tenga éxito. Eso no es deshonesto. Es racional. Pero su definición de "éxito" y la suya pueden no coincidir.

Un proveedor define el éxito del POC como un deal cerrado. Usted define el éxito del POC como una respuesta precisa a la pregunta "¿funcionará esto para nosotros?" Esos son objetivos diferentes, y crean comportamientos diferentes.

Los proveedores:

  • Lo guiarán hacia funciones que funcionan bien y lo alejarán de los casos de uso que descubren limitaciones
  • Resolverán los bloqueadores rápidamente durante el POC que tomarían semanas después del contrato
  • Proporcionarán recursos de soporte dedicados durante la evaluación que no están disponibles para los clientes normales
  • Enmarcarán la complejidad de integración de manera optimista porque el ingeniero de ventas confía en que es solucionable (el equipo de implementación lo descubrirá de otra manera)

Nada de esto es mentira. Es la consecuencia natural de un proveedor que despliega sus mejores recursos y personas más experimentadas en una evaluación de alto riesgo. Después del contrato, usted es un cliente normal.

La implicación es que debe probar activamente el POC, no aceptar el camino de menor resistencia. Use sus datos más desordenados. Pregunte sobre los casos de uso de los que está menos seguro de que funcionarán. Solicite una conversación con una referencia de cliente que tuvo un desafío de integración similar. Encuéntrela independientemente a través de una comunidad o su red, no una curada por el equipo de customer success del proveedor.

Los tres fallos más comunes de los POCs

Expansión del alcance sin ajuste del cronograma. Esto se mencionó en el diagnóstico del teatro, pero merece ampliación. La expansión del alcance en un POC casi siempre tiene buenas intenciones. El proveedor ve una oportunidad de mostrar más valor. Su champion quiere evaluar una capacidad que no planificó inicialmente. Alguien en el comité pregunta "¿también podemos ver cómo maneja X?" Cada solicitud individual parece razonable. Pero el efecto acumulativo es una evaluación que cubre todo de manera superficial en lugar del caso de uso original de manera profunda.

Solución: cualquier adición de alcance después de que se firma el brief del POC requiere una enmienda escrita que extiende el cronograma en consecuencia. Sin expansiones gratuitas.

Deriva de criterios de éxito. Un POC comienza con criterios claros. Tres semanas después, el proveedor no ha cumplido el criterio de integración. Ocurre una conversación. El criterio se reenmarca como "aspiracional" o "fase dos". Al final del POC, los criterios originales han sido reemplazados por una narrativa más suave sobre "señales prometedoras" y "roadmap de implementación".

Solución: los criterios de éxito originales están bloqueados una vez que se firma el brief del POC. Pueden ser formalmente enmendados por el comité de compra, pero el proveedor no puede renegociarlos unilateralmente a través de conversaciones informales con el champion.

Salida del champion durante la evaluación. La persona que diseñó el POC deja la empresa, se incorpora a un proyecto de mayor prioridad o es promovida a un rol donde ya no posee esta decisión. El POC continúa sin su conocimiento institucional. El nuevo propietario de la evaluación no escribió el brief, no entiende los criterios de éxito originales y es susceptible a la reenmarcación guiada por el proveedor.

Solución: un POC tiene dos propietarios internos, no uno. El propietario de respaldo recibe información sobre los criterios y el enfoque al inicio. Si el propietario principal se va, la evaluación no comienza desde cero.

La plantilla del brief de diseño de POC

Use esta estructura de una página antes de que comience cualquier POC de proveedor.

1. Declaración del problema de negocio. Un párrafo: ¿qué problema operacional o de ingresos específico estamos tratando de resolver? No "queremos mejores informes". Algo específico, como: "nuestro equipo de ventas pasa 6 horas por semana reconciliando manualmente los datos del pipeline entre nuestro CRM y nuestra herramienta de forecasting, y el resultado es un error de forecast que promedia un 22%".

2. Criterios de éxito (escritos). Tres a cinco criterios, cada uno falsificable. Para cada uno: qué estamos midiendo, cómo lo estamos midiendo y el umbral que constituye el éxito.

3. Requisitos de integración. Cada conexión de sistema requerida para el caso de uso base. Propietario y criterio de aceptación para cada uno.

4. Alcance del piloto. Qué equipo, cuántos usuarios, qué flujos de trabajo. Qué harán durante el POC, en su trabajo normal, usando datos reales.

5. Cronograma. Fecha de inicio, fecha de finalización, hitos clave de seguimiento. La fecha de la reunión de decisión se fija antes de que comience el POC.

6. Cláusula de fracaso. Un párrafo: ¿qué resultado nos llevaría a no proceder? Esta es la sección más útil y la que la mayoría de los compradores omite. Escribirla obliga a la claridad sobre lo que realmente les preocupa.

7. Roles. Propietarios de evaluación principal y de respaldo. Contacto principal del proveedor. Propietario de integración de IT. Lista de tomadores de decisiones para la revisión final.

Cinco criterios de éxito que todo POC de software debería tener

Independientemente de la categoría, estos cinco criterios deberían aparecer de alguna forma en cada POC de software empresarial:

Tasa de finalización del flujo de trabajo central. ¿Pueden los usuarios completar el flujo de trabajo principal previsto de manera independiente, sin soporte del proveedor, dentro del período piloto? Fije un umbral: el 80% de finalización para el día 10 es un punto de partida razonable.

Latencia y confiabilidad de la integración. Para cada integración requerida: los datos se sincronizan dentro del ventana definida (p. ej., 15 minutos) a una tasa de confiabilidad definida (p. ej., 99% o más durante el período del POC). Pruebe esto activamente, no preguntando al proveedor.

Manejo de casos extremos. Identifique tres a cinco casos de uso que representen situaciones no estándar en su entorno. Ejecútelos explícitamente durante el POC. Si la herramienta no maneja sus casos extremos, lo descubrirá después del contrato a menos que los pruebe ahora.

Calidad de la respuesta de soporte. Envíe una solicitud de soporte real durante el POC, no una fácil. ¿Cuánto tiempo tarda en llegar una respuesta sustantiva? ¿Quién responde? ¿Es la respuesta técnicamente precisa? La calidad del soporte post-contrato es a menudo la dimensión más subevaluada de una compra de software empresarial, y es una de las señales más claras en cualquier implementación de CRM.

Validación de portabilidad de datos. Antes de que termine el POC, exporte sus datos del sistema. Confirme que puede exportar todo lo que ingresó, en un formato que pueda usar realmente. Las preguntas sobre el vendor lock-in son más fáciles de evaluar con un contrato vacío que con una base de datos llena. El informe B2B Buying Disconnect de TrustRadius encuentra consistentemente que la portabilidad de datos y la calidad de integración están entre los principales factores que los compradores desean haber evaluado más rigurosamente antes de comprometerse.

Cómo se ve lo bueno

Los POCs que generan señales de compra confiables comparten algunas características. Son cortos: cuatro a seis semanas, no de extremo abierto. Corren con datos y flujos de trabajo reales. Los criterios de éxito se escribieron antes de que el ingeniero de ventas del proveedor se uniera a la primera llamada. El propietario de la evaluación tiene la autoridad para decir no, y todos en el comité de compra lo saben. El modelo de madurez de RevOps describe cómo se ve esa preparación organizacional en diferentes etapas: una función de RevOps de nivel 3 o superior típicamente ejecuta POCs mucho más estructurados que los equipos más tempranos en esa progresión.

También son ejecutados por el comprador, no por el proveedor. El proveedor apoya. El comprador dirige. Esa es una diferencia operacional significativa, y es una que la mayoría de los compradores tiene que establecer deliberadamente porque los proveedores llenarán el vacío si se los permite. La investigación de compras de tecnología de Forrester refuerza esto: las evaluaciones estructuradas y controladas por el comprador producen puntuaciones de satisfacción significativamente más altas 12 meses después de la implementación que las guiadas por el proveedor.

Un POC que descubre problemas reales antes del contrato es un regalo. La mayoría de los compradores no lo ve así en el momento. Ven una evaluación problemática que complica un deal que querían cerrar. Pero la alternativa siempre es más costosa: firmar un contrato y descubrir esos problemas durante la implementación es más perturbador que descubrirlos durante la evaluación.

Más artículos