Para encontrar socios de diseño (design partners) para un SaaS B2B, define el flujo de trabajo sobre el que necesitas aprender, identifica organizaciones que lo viven y pide una relación de trabajo acotada con un usuario real y un patrocinador interno. Acuerda qué aportará cada parte y cuándo se revisará el resultado. Una colaboración útil produce evidencia sobre el uso repetido; el entusiasmo en una demo es solo un punto de partida.
Elige la relación que realmente necesitas
Una organización colabora contigo a lo largo de varias iteraciones del producto. Ambas partes acuerdan una pregunta de aprendizaje, acceso a un flujo de trabajo relevante y revisiones periódicas con las personas que hacen el trabajo.
Una persona prueba una versión temprana y cuenta lo que ocurre. Usa la guía de usuarios beta cuando necesites una comprobación enfocada de usabilidad u onboarding sin un compromiso organizativo más largo.
Una organización compra un producto o servicio acordado. Un socio de diseño puede convertirse en cliente, pero el aprendizaje, el uso independiente y el pago van en campos separados de tu registro.
Parte de un flujo de trabajo y de una organización a tu alcance
- Escribe una sola incertidumbre: ¿puede un account manager usar nuestra checklist de traspaso durante una transición real de cliente sin que el fundador esté presente? Esto da a la colaboración un propósito concreto.
- Identifica organizaciones que ejecutan ese flujo de trabajo mediante páginas de empresa relevantes, descripciones públicas de procesos o presentaciones de personas que conocen el trabajo. Registra la fuente y la fecha; un cargo por sí solo no demuestra que el problema exista.
- Pide a quien te presente que te ponga en contacto con la persona que realiza el flujo de trabajo. En una primera conversación, pide a esa persona que describa un caso reciente, la solución alternativa actual y quién tendría que aprobar una prueba.
- Ofrece una conversación breve de definición del alcance antes de proponer un piloto. Explica lo que existe hoy y el soporte que puedes dar. Deja que la organización pueda decir que no sin verse empujada a una secuencia de ventas.
Copia la hoja de calificación de socios
Crea un registro por organización. Marca cada respuesta como observada, inferida o desconocida, y conserva su fuente/fecha. Un dato desconocido que impide el uso real es una pregunta que debes resolver antes de invitar a la organización a un piloto.
- Organización y segmento: [nombre]; [flujo de trabajo compartido con otros posibles clientes]; [por qué es representativa].
- Trabajo actual: [caso más reciente]; [solución alternativa]; [consecuencia de dejarlo como está]; [fuente/fecha].
- Personas: [usuario real]; [patrocinador interno]; [persona que puede autorizar la compra]; [qué roles siguen sin confirmar].
- Acceso: [datos de muestra que la organización puede compartir]; [entorno]; [responsable de permisos]; [requisitos previos bloqueados].
- Compromiso: [quién probará el flujo de trabajo]; [cadencia de revisión]; [tiempo disponible]; [próxima reunión acordada].
- Carga para el fundador: [esfuerzo de configuración]; [límite de soporte]; [peticiones a medida que quedan fuera de la dirección del producto].
- Decisión: [invitar, aclarar o declinar]; [evidencia en contra más sólida]; [pregunta sin responder]; [fecha de revisión].
Dos candidatos ficticios: el entusiasmo no basta
Estos son ejemplos didácticos inventados para un prototipo que coordina traspasos de clientes en agencias pequeñas. No son clientes de Soloop ni resultados medidos.
Un account manager puede explicar paso a paso un traspaso fallido reciente y tiene permiso para compartir una checklist anonimizada. La responsable de operaciones puede asistir a las revisiones periódicas. Su flujo de trabajo coincide con el prototipo. La capacidad de decisión de compra sigue siendo desconocida, así que la próxima conversación lo comprueba sin dar el pago por comprometido.
Un directivo entusiasta quiere una integración a medida para un flujo de trabajo que el prototipo no cubre. Ningún account manager puede participar y no hay datos de muestra disponibles. El fundador registra la petición, pero declina: el interés de un directivo no puede sustituir una colaboración viable.
Copia un brief de aprendizaje del piloto en una página
Complétalo junto con el socio después de la calificación. Es un documento de planificación operativa, no una plantilla de contrato. Elige una duración y una cadencia que ambas partes puedan sostener; el ejemplo de abajo es una decisión de calendario, no un referente universal.
- Pregunta y alcance: [una hipótesis]; [un flujo de trabajo]; [versión del prototipo]; [qué queda excluido].
- Participantes y acceso: [usuario y patrocinador]; [datos de muestra aprobados]; [límites de acceso]; [quién resuelve un requisito previo bloqueado].
- Calendario: [inicio]; [fin]; [fechas de revisión]; [quién observa el primer uso]. Por ejemplo, un periodo de aprendizaje de tres semanas con una revisión semanal.
- Aportaciones: [intentos y feedback del socio]; [configuración y soporte del fundador]; [límite de tiempo para trabajo a medida].
- Evidencia: [tarea intentada]; [completada de forma independiente o con ayuda]; [obstáculo]; [próximo intento]; [ubicación de las notas].
- Revisión de salida: [evidencia necesaria para ofrecer un producto de pago]; [incertidumbre que justifica una extensión acotada]; [condición para terminar]; [tratamiento acordado del acceso y los materiales compartidos].
Registra lo aprendido y luego gradúa, ajusta o termina
En cada revisión, pide al usuario que muestre su último intento antes de hablar de peticiones de funcionalidades. Registra dónde fue necesaria la ayuda del fundador. Un flujo de trabajo que solo se completó porque reparaste manualmente cada traspaso todavía no demuestra valor independiente del producto.
El uso repetido resuelve el trabajo previsto y un comprador quiere hablar de la oferta del producto. Acuerda por separado el alcance, el precio y el siguiente paso. Registra el pago solo después de que se produzca.
Un obstáculo concreto sin resolver impide otro intento significativo. Amplía solo con un cambio, una forma de observación y una fecha de fin acordados; evita un acuerdo indefinido de desarrollo a medida gratuito.
Cedar completa el periodo de aprendizaje y el account manager realiza un traspaso sin ayuda. Después, el comprador explica que el equipo rara vez cambia la titularidad de las cuentas y mantendrá su checklist actual. Registra: aprendizaje completado, sin compra y necesidad recurrente insuficiente. Termina el piloto e investiga organizaciones con traspasos más frecuentes.
Fuente y siguiente paso de investigación
Lleva a Soloop tu perfil provisional de socio y la pregunta abierta para plantear una tarea de investigación acotada que Soloop admita. Revisa su tarjeta de acción antes de continuar. Un informe de investigación puede fundamentar tu lista de candidatos; las conversaciones las sigues llevando tú y la colaboración la sigues gestionando tú.
a16z evalúa a los socios de diseño según urgencia, capacidad y representatividad, y trata la relación de aprendizaje por separado del pago eventual. Las hojas de trabajo y los escenarios ficticios anteriores son ejemplos editoriales de Soloop.
a16z: A Framework for Finding a Design Partner