Planteamiento y contexto aplicable
Eres responsable de un producto SaaS B2B de flujos de trabajo que necesita firma electrónica empresarial. Dos clientes estratégicos la requieren en un plazo de cuatro meses. Un proveedor afirma que puede realizar el lanzamiento en ocho semanas, cubre el 80% de los flujos de trabajo imprescindibles y cuesta $250,000 al año más uso. Proporciona una API de exportación de datos y una opción de rescisión con 90 días de aviso, pero tiene soporte limitado para marca blanca, firma sin conexión (offline) y enrutamiento personalizado de aprobaciones. Una estimación interna es de cinco ingenieros durante nueve meses, seguidos de trabajo continuo de seguridad, cumplimiento normativo y operaciones. Decide si desarrollar, comprar o utilizar un enfoque híbrido, y explica la evidencia, el piloto, los aspectos económicos, los riesgos y las condiciones de revisión que respaldan la recomendación.
Esta es una pregunta de criterio de producto para product managers, platform product managers y technical product managers. El material de entrevistas actual pregunta directamente a los candidatos cómo eligen entre una solución interna y una herramienta de terceros. La guía tecnológica oficial también trata el desarrollo interno, la compra, la reutilización y los enfoques combinados como decisiones del ciclo de vida que involucran necesidades de los usuarios, capacidades, costo total, integración, personalización, operaciones, contratos y retirada progresiva.
Cada cifra y detalle del producto en este planteamiento es un supuesto para la entrevista, no un estándar de la industria. La estimación de cinco ingenieros durante nueve meses representa 45 meses-ingeniero y aún excluye producto, diseño, seguridad, legal, infraestructura y operaciones continuas. Una respuesta sólida no debe declarar ninguna de las dos opciones como universalmente más barata. Debe mostrar qué supuestos rigen la decisión y cómo los comprobará el equipo.
Qué evalúa el entrevistador
La primera señal es si el candidato parte del problema del usuario y del objetivo de negocio. «Preferimos ser dueños de nuestro stack» y «la demostración del proveedor se veía bien» son puntos de partida débiles. La respuesta debe definir el resultado requerido por el cliente, el plazo límite de cuatro meses, los ingresos o la retención en riesgo, y qué capacidades diferencian realmente al producto.
La segunda señal es si los requisitos no negociables se separan de las preferencias ponderadas. La residencia de datos, seguridad, cumplimiento normativo, accesibilidad, confiabilidad, términos legales y la fecha límite de lanzamiento pueden invalidar una opción. Una puntuación ponderada no debe permitir que un precio atractivo compense el incumplimiento de un requisito de conformidad normativa.
La tercera señal es la integridad económica. El costo de desarrollo incluye descubrimiento, implementación, infraestructura, pruebas, mantenimiento, respuesta a incidentes, revisiones de seguridad, actualizaciones y el costo de oportunidad de 45 meses-ingeniero. El costo de compra incluye tarifas de suscripción y uso, integración, gestión de proveedores, trabajo personalizado, niveles de soporte, cambios de precio, migración y salida. Una comparación de licencias a un año frente al tiempo inicial de codificación no constituye el costo total de propiedad.
La cuarta señal es la validación práctica y la reversibilidad. Un candidato sólido propone un piloto utilizando un flujo de trabajo real, pequeño pero difícil, prueba la exportación de datos y el comportamiento ante fallos, y limita el acoplamiento (lock-in) mediante límites claros del sistema. La decisión también necesita responsables, supuestos medidos y detonantes explícitos para revisarla.
Preguntas para clarificar antes de responder
- ¿Qué resultado de cliente y de negocio debe lograrse en cuatro meses? Confirma los ingresos afectados, la retención, los compromisos contractuales y si un lanzamiento limitado satisface a los clientes.
- ¿Cuáles requisitos son verdaderos criterios excluyentes (hard gates)? Clarifica la verificación de identidad, evidencia de auditoría, residencia de datos, cifrado, accesibilidad, disponibilidad, uso sin conexión, marca blanca, enrutamiento y obligaciones legales.
- ¿Qué hace que esta capacidad sea diferenciadora? El motor de firma puede ser infraestructura genérica (commodity), mientras que el enrutamiento específico de la industria, las políticas, las plantillas y los flujos de auditoría crean una ventaja de producto.
- ¿Qué significa realmente «80% de cobertura»? Clasifica el 20% faltante en bloqueos para el lanzamiento, brechas configurables, necesidades futuras y flujos de trabajo específicos del producto que pueden construirse alrededor del proveedor.
- ¿Qué tan confiable es la estimación interna? Pregunta si los cinco ingenieros durante nueve meses incluyen descubrimiento, certificaciones, seguridad, infraestructura, migración, herramientas de soporte y propiedad en producción.
- ¿Cuál es el volumen y crecimiento esperados? El uso afecta los costos económicos del proveedor, la planificación de capacidad, los límites de tasa (rate limits) y el punto en el que una opción de desarrollo interno podría volverse financieramente atractiva.
- ¿Cuáles son los riesgos operativos y comerciales del proveedor? Revisa niveles de servicio, evidencia de seguridad, respuesta a incidentes, subprocesadores, roadmap, términos de precios, propiedad de los datos, calidad de exportación, rescisión y viabilidad del proveedor.
- ¿Qué proyectos alternativos pierden capacidad si el equipo opta por desarrollar? El costo de oportunidad es una decisión de producto, así que compara el valor esperado del trabajo diferido del roadmap con el valor de ser dueño de la firma electrónica.
Marco de respuesta de 30 segundos
«Primero definiría el resultado para el cliente y colocaría el cumplimiento normativo, la seguridad, la confiabilidad, el control de datos y el plazo de cuatro meses en criterios excluyentes. Luego clasificaría la capacidad en infraestructura genérica de firma y flujo de trabajo diferenciador, compararía desarrollar, comprar e híbrido en un horizonte común de tres años, e incluiría el costo de oportunidad y el costo de salida. Con los supuestos del caso, un desarrollo puramente interno incumple el plazo límite, mientras que el proveedor cubre la mayoría de las necesidades en ocho semanas. Por lo tanto, mi recomendación provisional es híbrida: comprar el motor de firma y desarrollar nuestra capa distintiva de enrutamiento, políticas y experiencia. Antes de comprometernos, ejecutaría un piloto pequeño pero exigente, probaría seguridad, integración, recuperación de fallos, exportación de datos y la economía del uso real, y luego documentaría los supuestos y detonantes que nos llevarían a renegociar, cambiar de proveedor o internalizar más capacidades».
Esta apertura toma una decisión sin fingir que la evidencia está completa. El resto de la respuesta debe demostrar que la recomendación supera los criterios excluyentes, un análisis económico realista y una prueba de salida.
Respuesta profunda paso a paso
Comienza con un contrato de decisión de una sola página. Establece el resultado para el cliente, la fecha de decisión, el responsable directo, las opciones disponibles, los criterios excluyentes, el horizonte de decisión, los supuestos, la evidencia requerida y el costo de la demora. Para este caso, asume que el objetivo es un lanzamiento limitado apto para producción en un plazo de cuatro meses para los dos clientes estratégicos. Utiliza un horizonte económico de tres años como supuesto de entrevista, ya que es lo suficientemente largo como para visibilizar los costos recurrentes y de migración sin pretender hacer un pronóstico incognoscible del ciclo de vida total.
A continuación, descompón la capacidad. La firma criptográfica, la verificación de identidad, el manejo de certificados, la generación de evidencia y la disponibilidad base son probablemente infraestructura compartida. El enrutamiento específico de la industria, permisos, plantillas, manejo de excepciones, personalización de marca y la experiencia de auditoría del producto pueden ser diferenciadores. Esta descomposición evita que el equipo trate la «firma electrónica» como una única característica indivisible y crea una opción híbrida creíble.
Aplica los criterios excluyentes antes de cualquier puntuación:
| Criterio | Evidencia requerida | Consecuencia en la decisión |
|---|---|---|
| Plazo límite | Plan creíble para atender a los dos clientes en cuatro meses | El desarrollo puro de nueve meses queda descartado a menos que cambie el alcance o el compromiso |
| Seguridad y cumplimiento | Revisión de arquitectura, certificaciones, flujo de datos, subprocesadores, cifrado, proceso de incidentes | Un requisito no resuelto y sustancial descalifica al proveedor |
| Control legal y de datos | Propiedad de los datos, evidencia de auditoría, retención, exportación, eliminación, rescisión | Términos inaceptables bloquean la compra independientemente del precio |
| Confiabilidad y recuperación | Niveles de servicio, capacidad, observabilidad, comportamiento ante reintentos, proceso de recuperación | Un comportamiento de fallos que interrumpa los flujos de trabajo del cliente bloquea el lanzamiento |
| Ajuste con flujos de trabajo críticos | Demostración de soporte para cada flujo de trabajo crítico para el lanzamiento | Un bloqueo no cubierto requiere configuración, una capa envolvente (wrapper) u otra opción |
Solo las opciones que superen estos filtros entran en una matriz de comparación. La ponderación debe reflejar el objetivo declarado, y el equipo debe comprobar si un cambio moderado en las ponderaciones invierte el resultado:
| Factor de decisión | Desarrollar (Build) | Comprar (Buy) | Híbrido |
|---|---|---|---|
| Tiempo para generar valor al cliente | La estimación de nueve meses incumple el plazo del caso | La estimación de ocho semanas del proveedor se ajusta si la integración tiene éxito | Puede ajustarse si la capa envolvente se mantiene acotada |
| Control estratégico | Máximo control sobre todo el stack | Limitado por el roadmap y los puntos de extensión del proveedor | Ser dueño de las políticas y la experiencia diferenciadoras |
| Uso inicial de capacidad | Al menos 45 meses-ingeniero según la estimación | Equipo de evaluación e integración más reducido | Integración más ingeniería enfocada en el flujo de trabajo |
| Responsabilidad continua | Seguridad, cumplimiento, confiabilidad, soporte y actualizaciones se quedan internamente | El proveedor asume más trabajo de plataforma; el equipo interno es dueño de la integración | Las responsabilidades deben ser explícitas en el límite de integración |
| Personalización | Mayor potencial, con riesgo de entrega | Soporte limitado para marca blanca, modo sin conexión y enrutamiento | Añadir solo las brechas específicas del producto fuera del núcleo del proveedor |
| Riesgo de salida | Menor dependencia de proveedores, pero alto costo irrecuperable de propiedad | Riesgo de migración y precios | Reducido mediante un modelo de datos propio y un límite de adaptador reemplazable |
Reconstruye el costo total de propiedad sobre los mismos tres años. Para desarrollar, incluye la estimación de 45 meses-ingeniero, trabajo de producto y diseño, revisión legal y de seguridad, infraestructura, pruebas, herramientas operativas, guardias (on-call), soporte, mantenimiento, actualizaciones y el valor del trabajo del roadmap retrasado por esos ingenieros. Para comprar, incluye la licencia anual de $250,000, el uso previsto, la implementación, el soporte premium, la revisión de seguridad y compras, la responsabilidad de la integración interna, la personalización, escenarios de aumento de precios y el trabajo de migración o salida. Para el enfoque híbrido, combina el costo del proveedor con la capa acotada de la que la empresa decide ser dueña.
No conviertas cada incertidumbre en una cifra exacta en dólares. Utiliza rangos para el costo de ingeniería, el crecimiento del uso, la carga de soporte y el esfuerzo de migración, y luego realiza un análisis de sensibilidad. Por ejemplo: ¿a qué volumen de uso anual, aumento de precio o carga operativa interna cambia la opción preferida? Una recomendación que solo resulta ganadora bajo una estimación optimista es frágil.
El análisis del costo de oportunidad debe ser explícito. Pregunta qué podrían entregar de otro modo cinco ingenieros durante nueve meses, cuánto valor para el cliente o el negocio generan esos proyectos y si la empresa posee una experiencia escasa en seguridad y cumplimiento normativo. Cuarenta y cinco meses-ingeniero no son «gratuitos» porque los salarios ya estén presupuestados. Son una decisión de asignación de recursos escasos.
Antes de firmar un contrato a largo plazo, ejecuta un piloto con tiempo acotado (time-boxed) sobre un flujo de trabajo pequeño pero complejo. Utiliza un documento real y representativo, la ruta de enrutamiento más compleja y crítica para el lanzamiento, roles realistas de identidad y permisos, y un volumen similar al de producción. Prueba:
- el tiempo de integración y de obtención del primer valor;
- la experiencia del usuario final y del administrador;
- evidencia de seguridad, privacidad, accesibilidad y auditoría;
- latencia, límites de tasa, fallos parciales, reintentos, callbacks duplicados y recuperación;
- observabilidad y escalamiento de soporte;
- exportación y eliminación de datos, y una simulación de salida del proveedor;
- el esfuerzo real requerido para cerrar el 20% faltante.
Define los umbrales del piloto antes de ver los resultados. Una demostración pulida del camino feliz (happy path) es insuficiente. Si un flujo de trabajo faltante representa un bloqueo regulatorio o contractual, una «cobertura del 80%» puede ser efectivamente cero para el lanzamiento. Si las brechas son de enrutamiento y personalización de marca específicas del producto que pueden implementarse limpiamente fuera del núcleo del proveedor, la opción híbrida se fortalece.
Diseña la reversibilidad como parte del producto, no como un proyecto de migración futuro. Mantén el modelo canónico de documento, firmante, consentimiento, estado y auditoría de la empresa independiente de los identificadores del proveedor. Coloca las llamadas específicas del proveedor detrás del límite de integración existente, persiste los eventos necesarios para reconstruir el estado, prueba las exportaciones y define el comportamiento degradado cuando el proveedor no esté disponible. Los términos contractuales deben cubrir la propiedad de los datos, el formato de exportación, la eliminación, la notificación de cambios sustanciales, protecciones de precios donde sea posible, niveles de servicio, rescisión y asistencia para la transición.
Bajo los supuestos del caso, recomienda la opción híbrida: comprar el motor de firma genérico para cumplir con el compromiso de cuatro meses y desarrollar el enrutamiento diferenciado, las políticas, las plantillas y la experiencia de producto a su alrededor. Limita el primer contrato y el alcance inicial de modo que el piloto pueda invalidar la elección. Esta recomendación cambia si el proveedor no supera un criterio excluyente, si el 20% faltante contiene bloqueos estructurales costosos, si la economía de uso se deteriora materialmente o si la tecnología de firma propietaria se convierte en una ventaja competitiva defendible.
Tras el lanzamiento, compara la realidad con el contrato de decisión. Monitorea el tiempo hasta el primer documento firmado, la finalización de flujos de trabajo, los fallos de firma, las horas de soporte, el mantenimiento de ingeniería, el rendimiento según los niveles de servicio, el costo de uso por flujo completado, la adopción del cliente, los ingresos retenidos o expandidos y el esfuerzo requerido para cada nuevo flujo de trabajo. Revisa la decisión al renovar el contrato y antes si se dispara algún detonante: fallos repetidos del servicio, aumentos significativos de precio, fallos en la exportación, conflictos estratégicos en el roadmap, rápido crecimiento del volumen, cambios normativos o personalización recurrente suficiente para que la capa envolvente se esté convirtiendo en una segunda plataforma de firma.
Respuesta de ejemplo de alta calidad
«Comenzaría definiendo el resultado y los criterios excluyentes. En este caso, el resultado es un lanzamiento con capacidad de producción para dos clientes estratégicos en cuatro meses. Trataría la seguridad, el cumplimiento normativo, la propiedad y exportación de datos, la confiabilidad, la cobertura de flujos de trabajo críticos y el plazo límite como aspectos no negociables. También confirmaría los ingresos o la retención en riesgo y si una disponibilidad limitada cumple con el compromiso hacia los clientes.
Descompondría la capacidad antes de comparar opciones. El motor de firma, la verificación de identidad, los certificados y la evidencia estándar son probablemente infraestructura genérica. Nuestro enrutamiento específico de la industria, las políticas, las plantillas, los permisos y la experiencia de auditoría pueden ser la diferenciación. Eso crea tres opciones reales: desarrollarlo todo, comprar todo lo que ofrece el proveedor, o comprar el motor y desarrollar la capa de producto.
La estimación de desarrollo puro es de cinco ingenieros durante nueve meses, o 45 meses-ingeniero antes de considerar producto, diseño, seguridad, legal, infraestructura y operaciones continuas. Incumple el plazo de cuatro meses bajo los supuestos dados. El proveedor promete un lanzamiento en ocho semanas y una cobertura del 80%, pero no aceptaría esas cifras sin un piloto ni permitiría que una puntuación compense una falla de cumplimiento normativo.
Primero realizaría revisiones de seguridad, legal, datos, confiabilidad y flujos de trabajo críticos para el lanzamiento. Luego compararía las opciones viables en un horizonte común de tres años. El TCO de desarrollo incluye implementación, operaciones en producción, mantenimiento, actualizaciones, respuesta a incidentes y el costo de oportunidad del roadmap que esos cinco ingenieros posponen. El TCO de compra incluye la tarifa anual de $250,000, uso, integración, soporte, propiedad interna, cambios de precio, personalización y salida. Usaría rangos y probaría en qué punto el volumen o los precios del proveedor revierten el resultado.
Mi recomendación provisional es híbrida. Comprar el motor de firma genérico para que podamos cumplir de manera creíble con la fecha del cliente y desarrollar nuestro enrutamiento y experiencia distintivos fuera del núcleo del proveedor. Antes de firmar contrato, realizaría un piloto sobre un flujo de trabajo pequeño pero complejo con permisos y volúmenes realistas. Probaría el requisito de enrutamiento más difícil, la evidencia de seguridad, accesibilidad, fallos parciales, reintentos, escalamiento de soporte, exportación de datos, eliminación y una salida simulada. El 20% faltante debe clasificarse en bloqueos, configuración y extensiones específicas del producto.
Protegería la reversibilidad manteniendo nuestro modelo de datos canónico independiente de los IDs del proveedor, aislando las llamadas específicas del proveedor, persistiendo los eventos necesarios para reconstruir el estado y negociando propiedad de datos, exportación, eliminación, niveles de servicio, protecciones contra cambios y aumentos de precios, rescisión y soporte para la transición. El alcance y el contrato iniciales deben ser lo suficientemente limitados para que la evidencia fallida aún pueda cambiar la decisión.
Tras el lanzamiento, compararía la adopción real, la finalización de flujos de trabajo, la tasa de fallos, las horas de soporte, el mantenimiento de ingeniería, el costo de uso y el impacto en los ingresos con los supuestos. Revisaríamos en la renovación o antes tras un fallo de servicio, un aumento sustancial de precio, un cambio normativo, un problema de exportación, un rápido crecimiento de volumen o trabajo personalizado repetido. Si el proveedor falla un criterio excluyente, no compramos. Si el piloto tiene éxito y las brechas se mantienen en nuestra capa diferenciadora, el modelo híbrido nos da velocidad ahora sin renunciar a la parte del producto de la que debemos ser dueños».
Errores comunes
- Partir de una preferencia ideológica → «Siempre desarrollamos internamente» o «compra software genérico» omite la necesidad real del usuario y las restricciones → Define primero el resultado, los criterios excluyentes y la capacidad diferenciadora.
- Incluir criterios excluyentes en una puntuación ponderada → Un precio bajo puede ocultar matemáticamente un requisito fallido de seguridad o legal → Elimina las opciones no conformes antes de puntuar preferencias.
- Comparar el precio de la licencia con el tiempo de desarrollo de código → Operaciones, mantenimiento, costo de oportunidad, integración, personalización y salida desaparecen → Utiliza el mismo horizonte y un modelo completo de TCO para cada opción.
- Tratar el 80% de cobertura de funcionalidades como evidencia sólida → Un solo flujo de trabajo faltante que sea crítico para el lanzamiento puede invalidar el producto → Clasifica cada brecha como bloqueo, configuración, extensión o aplazamiento.
- Confiar en la demostración de un proveedor → El comportamiento en el camino feliz no revela problemas de integración, recuperación, auditoría o exportación → Ejecuta un piloto con un flujo de trabajo real, pequeño pero exigente, con umbrales definidos previamente.
- Asumir que los ingenieros internos son gratuitos → Los salarios ya presupuestados siguen representando capacidad escasa en el roadmap → Nombra los proyectos, el valor y el aprendizaje retrasados por 45 meses-ingeniero.
- Elegir comprar sin un diseño de salida → Los IDs del proveedor, el estado propietario y las exportaciones no probadas generan acoplamiento (lock-in) → Sé dueño del modelo canónico, aísla la integración, prueba la exportación y negocia términos de transición.
- Tomar una decisión permanente basada en hechos temporales → El volumen, los precios, el cumplimiento normativo, las capacidades y la estrategia cambian → Registra los supuestos y establece detonantes de revisión medibles.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: El proveedor no cumple con un requisito estricto de cumplimiento normativo, pero promete solucionarlo en seis meses. ¿Qué haces?
No trates una promesa en el roadmap como evidencia actual. Confirma si el requisito es legal o contractualmente obligatorio para los primeros clientes. Si lo es, el proveedor no supera el criterio excluyente. Las opciones incluyen buscar otro proveedor, un lanzamiento más acotado que no procese los datos afectados o un compromiso revisado con el cliente. Un control interno temporal solo es aceptable cuando los responsables de seguridad y legal lo aprueban y el riesgo residual es explícito.
Pregunta de seguimiento 2: Finanzas dice que el proveedor es demasiado costoso porque los ingenieros ya están en la nómina. ¿Cómo respondes?
Muestra el balance en la asignación de recursos en lugar de argumentar desde la contabilidad salarial. El desarrollo consume al menos 45 meses-ingeniero según la estimación del caso y retrasa otro valor del roadmap. Añade infraestructura, seguridad, cumplimiento normativo, soporte, guardias (on-call), mantenimiento y trabajo de actualización. Luego compara el rango a tres años con los costos de licencia, uso, integración y salida del proveedor. La decisión correcta aún puede ser desarrollar internamente, pero el hecho de que «ya estén empleados» no hace que la capacidad sea gratuita.
Pregunta de seguimiento 3: El uso crece mucho más rápido de lo esperado y las tarifas del proveedor se vuelven poco atractivas. ¿Reconstruyes internamente de inmediato?
Primero valida la economía unitaria, los niveles de contrato, los descuentos y el costo de cambio. Renegocia utilizando el volumen medido, compara proveedores alternativos y actualiza la estimación de desarrollo con lo que el equipo aprendió en producción. Si el crecimiento de costos cruza repetidamente el detonante documentado y la capacidad puede operarse de forma segura internamente, inicia una migración por etapas detrás del límite que la empresa posee. Una reescritura de emergencia puede costar más que un período controlado de tarifas elevadas del proveedor.
Pregunta de seguimiento 4: Los ingenieros argumentan que el 20% faltante contiene la experiencia de cliente más valiosa. ¿Cambia eso la decisión?
Refuerza la opción híbrida si esas brechas pueden vivir limpiamente en la capa de enrutamiento, políticas e interfaz de la empresa. Debilita la opción del proveedor si las extensiones requieren cambios no soportados dentro del motor de firma, duplican estados críticos o crean soluciones provisionales frágiles que bloquean futuras actualizaciones. Utiliza el piloto para medir el esfuerzo real de extensión y el límite de mantenimiento, y luego actualiza la recomendación.
Pregunta de seguimiento 5: ¿Cómo sabrías que la arquitectura híbrida se está convirtiendo en la opción incorrecta a largo plazo?
Presta atención a incidentes repetidos del proveedor, empeoramiento del costo por flujo completado, fallos en las exportaciones, conflictos en el roadmap, brechas de cumplimiento normativo y trabajo personalizado que se filtre hacia una gran plataforma paralela. Compara también el esfuerzo interno de soporte e ingeniería con los supuestos originales. Si varios detonantes persisten y un caso revisado de desarrollo interno o de un proveedor alternativo supera los mismos criterios excluyentes, programa una transición planificada. La reversibilidad significa que el equipo puede cambiar de rumbo con evidencia, no que cambiar sea gratis.