Pospuse salir a buscar clientes para Zaplink porque pensé que las empresas más grandes querrían usar su propio número de WhatsApp.
Ninguna me lo había pedido todavía.
Zaplink permite que los negocios ofrezcan inicio de sesión por WhatsApp. Hay dos formas de manejar el número que envía los mensajes: usar uno de Zaplink o conectar el tuyo. Primero construí la versión administrada, en la que el mensaje sale del número de Zaplink.
El mensaje incluye el nombre del negocio, pero el número no es suyo.
Pensé que eso generaría un problema de confianza. Un cliente más grande querría que el número que enviara el mensaje tuviera su propia identidad. Darle esa opción también haría que el producto se sintiera más completo.
Era un requisito plausible. Con eso me alcanzó para dedicarle tiempo que podría haber usado para contactar clientes.
Con tiempo y recursos limitados, esas decisiones pesaban. El desarrollo del producto fue retrasando la prospección. Estaba mejorando lo que podía ofrecer antes de averiguar si las personas a las que podía acercarme necesitaban esa mejora.
Un cliente con el que todavía no has hablado puede terminar teniendo una lista de requisitos sorprendentemente detallada.
Cuando empecé a vender a clientes más pequeños, no tenían problema con que el mensaje de inicio de sesión llegara desde Zaplink. El mensaje llevaba el nombre de su negocio. Lo veían parecido a recibir un SMS desde un número genérico.
Eso no resolvía qué exigirían las empresas más grandes. Me decía algo más concreto y útil para las conversaciones que sí estaba teniendo: esos clientes aceptaban usar el número de Zaplink.
La versión administrada ya me daba algo que podía mostrarles. Podría haber puesto a prueba esa suposición antes.
Por eso cuesta detectar este tipo de situación. Darle al cliente la posibilidad de usar su propio número tiene una razón válida. Puedes explicar el trabajo, mostrar avances y describir un producto más capaz al terminar. Nada de eso te dice si hace falta hacerlo antes de la siguiente conversación de venta.
Cuando un producto ya funciona, todavía hay muchas mejoras que puedes justificar. El proceso para empezar a usarlo podría ser más claro. La documentación podría estar mejor. Otra integración podría volverlo útil para otro tipo de cliente.
Cada tarea puede tener sentido por separado. Juntas pueden seguir recorriendo la conversación con un comprador hacia otra fecha del calendario.
Además, desarrollar te da un lugar relativamente claro donde poner tu esfuerzo. Puedes dividir una función en tareas y ver cómo se van terminando. Vender introduce preguntas sobre las que tienes mucho menos control. ¿Puedes llegar a quien compra? ¿Le importa el problema? ¿Entiende lo que ofreces? ¿Confía en que puedes cumplir?
Otra sesión de desarrollo puede dejar intactas todas esas preguntas y, aun así, darte algo concreto que mostrar al final del día.
En este caso, querer un producto más completo me dio una razón para seguir construyendo. Tenía una suposición sin validar, le asigné tiempo y la prospección ocurrió después. Esa es la decisión que vale la pena revisar.
Antes de dejar que la siguiente mejora retrase una conversación de venta, vale la pena hacerse cuatro preguntas.
-
¿Quién se ha encontrado con este problema?
Ponle nombre a la persona o empresa y describe qué pasó. Si la respuesta es un tipo de cliente al que esperas venderle, anótalo como una suposición. En mi caso, esperaba que las empresas más grandes quisieran su propio número. No tenía una solicitud de alguna de ellas que estableciera ese requisito.
-
¿Realmente le impidió comprar o usar el producto?
Que a alguien le guste una opción es distinto de que no pueda avanzar sin ella. Pregunta qué haría con la versión actual y qué, específicamente, se lo impediría. Los clientes más pequeños con los que hablé aceptaban el número administrado. Eso me dio evidencia sobre ellos, sin responder por todos los demás.
-
¿Puedo ayudarle a empezar con la versión actual?
Considera qué puedes entregar hoy, incluyendo la configuración que puedas hacer tú. Con Zaplink también ofrecí integraciones manualmente antes de construir la plataforma. Una experiencia de software más completa no siempre es necesaria para empezar a entregar algo útil. Deja claro qué va a recibir el cliente y qué ayuda necesita para usarlo.
-
¿Qué aprendería si se lo mostrara ahora?
La objeción podría tener que ver con esa función. También podría ser el precio, la explicación, la confianza en el proveedor o que no estés hablando con la persona indicada. Una conversación te permite distinguir esas posibilidades. Construir primero la función te deja adivinando durante más tiempo.
Hay buenas razones para esperar. Si el producto todavía no puede cumplir de forma confiable con lo que ofreces, eso merece atención. Una falla que tú detectaste en el funcionamiento principal también es evidencia; no necesitas esperar a que un cliente la padezca. Quizá tengas que corregir el problema o acotar la oferta antes de pedirle a alguien que dependa de ella.
La distinción útil está entre un problema demostrado para cumplir lo prometido y un requisito imaginado para sentir que el producto ya está terminado.
Haz la prueba con las siguientes tres tareas que tienes pendientes de desarrollar. Junto a cada una, escribe qué evidencia la respalda y si esa evidencia justifica retrasar una conversación con un cliente. Donde tengas una suposición, escribe la pregunta que necesitas hacer.
Para mi decisión sobre el número propio, la pregunta podría haber sido: ¿usarías la versión administrada, en la que el mensaje de inicio de sesión lleva el nombre de tu negocio, pero sale del número de Zaplink?
Al final obtuve una respuesta de los clientes más pequeños con los que hablé. Podría haber preguntado antes de tratar mi suposición como un requisito.
¿Qué tarea de tu lista necesita una conversación antes de necesitar más código?
Hec Sánchez es ingeniero de producto y CTO fraccional en México. Desarrolla software y trabaja con agencias y fundadores en productos, integraciones y liderazgo técnico.
Más sobre Hec →