El ratio del billón de dólares

Mientras se inyectaba su medio litro de café habitual, Jan pudo escuchar en KCBS el parte meteorológico: tras varios días sin lluvia, las ligeras precipitaciones que empezaron ayer por la tarde ganarían intensidad a partir de las nueve.  

Ese miércoles aterrizó muy muy pronto en su oficina. No solía ponerse nervioso, pero aquella mañana lo estaba por primera vez en décadas.  Seguía dándole vueltas a las conversaciones de los últimos días, pero en este punto no quedaba más que asumir que ya nada iba a cambiar sustancialmente. Tan buen momento sería ahora como la semana que viene. Así que, con la decisión ya racionalizada, sacó su android del bolsillo, entró al grupo de WhatsApp que compartía con Brian y Jim, y les dijo: «Firmemos ya. Os espero en el edificio público que está al principio de Moffet Blvd, al otro lado del Transit Center».

Brian recibió el mensaje mientras conducía de camino a la oficina. Aún conociendo lo reservado que siempre había sido Jan, entendió al momento por qué quería firmar allí. Además de extremadamente reservado, era muy orgulloso. Y ese día, tras muchos años esperando, Jan iba a cobrarse una deuda contra su destino.

Jim no leería el mensaje hasta acabar su sesión matinal de bikram yoga.

No sé qué le pasaría a Jan por la cabeza mientras caminaba el escaso kilómetro que separaba sus oficinas de la sede de los servicios sociales en los que había reunido a su socio y a su principal inversor. Supongo que recordaría su infancia en Kiev. O en cómo lo trató el primer jefe que tuvo, en el supermercado en el que fregaba el suelo al poco de llegar a USA. O en las ironías del destino: justo los que no le quisieron contratar al abandonar su anterior trabajo, iban ahora a pagar un imperio por asegurarse su base de datos. A mí me gusta imaginármelo tarareando El hombre que asaltó Monte Carlo («Dame Fortune smiled upon me // As she'd never smiled before») mientras acelera un poco el paso al notar las primeras gotas.

Lo que es la vida, Benavida. Para poder tener la oportunidad de hoy, tuvo que aprender a programar a toda velocidad: comprando, exprimiendo y devolviendo los libros que ni aún siendo de segunda mano podía pagar. Y tras empezar así, esa misma tarde podría comprarse todas las editoriales técnicas del mundo. Y alguna más por darse el gusto. Nueve billones de dólares pueden comprar muchas cosas, más de las que cualquier persona sensata puede soñar. También pensó que podía comprarlo todo menos el volver a pasar un rato con su madre, o comerse alguno de los nalysnkys que ella le preparaba y cuyo sabor volvía de vez en cuando del pasado a enraizarse en sus entrañas hasta hacerlo llorar. El destino no deja de ser irónico: puedes meterte de lleno en la lista Forbes, o hacerte con cualquier cosa que haya en el mundo, y justamente no puedes comprar lo único que te gustaría tener.  También pensó, mientras se ajustaba la capucha sobre su pelo ya húmedo, que hay que ser muy pobre de espíritu para creer que el dinero lo compra todo. Y en lo absurdo de que subiese gente al Everest para probar la calidad de la chaqueta que él llevaba, aún sabiendo que ese modelo tan caro se vendía casi exclusivamente a casual commuters de la bahía. Absurdo todo.

No tuvo que esperar mucho en el párking del edificio hasta que Brian llegó. Educado por el comunismo a hacer colas desde niño, le daba igual esperar. Y además  el sonido de la lluvia calmaba su ansiedad.

«Pero qué cojones tienes... ¿Justo aquí lo tenemos que firmar?», le dijo Brian sonriendo nada más verlo.

Jan se encogió de hombros. Y le devolvió la sonrisa.

Jim tardaba en llegar. «Jodidos VCs. Ni en días como hoy pueden evitar hacerte esperar», dijo Brian intentando romper el silencio con algo ingenioso. Jan volvió a encogerse de hombros. Y a sonreír.

Así en silencio estuvieron esperando algo más de media hora bajo la lluvia. Todo el respeto que Jim había conseguido ganarse, casi lo pierde al aparecer en pleno febrero en uno de sus descapotables. «Ya hay que ser gilipollas», pensó Jan durante un microsegundo. Más o menos lo que tardó en recordar que en buena medida estaban ahí gracias a Jim. Luego se preguntó, supongo que por el frío que hacía esa mañana, si al comprar un descapotable te dan la opción de ponerle asientos calefactados. Y se dio cuenta de que en pocas horas podría encargarse el coche que le diese la gana con todos los extras que le diese la gana. Hasta con un cockpit digital enorme, como los que fabricaba ahora aquel colgado que conoció en un burning man años atrás. A Jan le encantaba pensarlo todo.

«Os juro que no me han cambiado una coma desde la versión de ayer por la noche», dijo Jim, aún intuyendo que ninguno de ellos dos había revisado los cambios del contrato en los últimos días. «Si no firmamos hoy, Sheryl me mata. Os lo digo en serio. Tiene pánico a Mark. Me mata. Ella me mata. En serio que me mata».

Jim era un VC de verdad. De los de antes. De los que en nuestro sector viene a ser de los de toda la vida. Un VC profesional, que jamás cometería el error de dar un traspiés que hipotecase un acuerdo futuro. Entre vosotros y yo: lo que pensase o dijese Sheryl a partir del momento en que estampasen su firma en el contrato, a Jan y a Brian les daba exactamente igual.  Se la soplaba, por decirlo finamente. O se la sudaba, por entendernos. A Jim no, y por eso le importaba tanto cerrar la venta. Porque nunca sabes, aunque lo intuyes, sí tendrás que volver a acercarte a Facebook para venderles otra empresa. Aunque pensándolo bien, con el carry que se iba a llevar tras esta operación, igual no volvía a perder el tiempo tratando con personas como Sheryl. Podría despedirse del trabajo y del sector por todo lo alto, y además perderla de vista. Todo un combo dominicano.

«Tú me has conocido triunfando», le dijo Jan. «Pero hace 20 años venía a estas oficinas a por cupones de alimentos. Venía y hacía cola en plena madrugada para que mi madre no necesitase trabajar aún más. Horas y horas bajo la lluvia tragándome mi orgullo delante de esta misma puerta. ¿Y sabes qué? Siempre, siempre, siempre supe que un día como hoy llegaría. O llegué a creérmelo para poder sobrellevarlo. Así que pásame un boli, que vamos a firmar ya ese puto contrato encima de esta puta puerta».

Obviamente, mucho de lo contado arriba es una recreación. Aunque no creo que se aleje de la realidad que se vivió el 19/Feb/2014 en el párking de aquel edificio ya derruido. Pero para mí, lo más importante de aquella mañana es que la venta de WhatsApp batía uno de mis ratios preferidos: el de la división del importe de la venta de una empresa entre su número de empleados. Redondeando números: 19 billones de dólares entre 55 empleados supone asignar un valor medio de 350 millones por empleado. Por daros contexto: la siguiente operación en este ránking es la de Instagram, pero se queda lejos al conseguir apenas 75 millones por empleado. Y se aleja más del récord de casi 20 millones de euros por empleado que consiguió en nuestro país el fundador de MilAnuncios.

¿Y toda esta perversión por los números con muchos ceros de dónde viene? Pues de que me sirve para tomar decisiones a la hora de diseñar un producto digital. Es uno de los frameworks que tengo en mi cabeza: ¿sería útil este producto para la primera empresa que consiga llegar al ratio del billón de dólares?

Aterricemos la idea.

Aunque ya ha nacido gente capaz de generar 1 billón a base de remezclar electrones reciclados, no los vamos a tener en cuenta en nuestro análisis. Ni Satoshi, ni los Winklevoss, ni especuladores con materias primas a los que perdona en su último día un presidente, ni gestores de hedge funds con una ambición nacida de carencias afectivas en la infancia. Vamos a ponernos en la cabeza a una persona honesta que desarrolla y vende un producto/servicio digital. Y digo una persona y no un equipo para facilitar el exit de esa empresa manteniendo nuestro ratio. Todo un ejemplo de bootstrapper.

Para llegar a ese billón de valoración no es necesario conocer el tipo de producto o servicio que ofrece. Pero si tenemos que elegir entre si ofrece algo caro en un mercado pequeño, o algo más accesible para un mercado enorme, probablemente sea esto último. Así que hemos de producir una herramienta útil para alguien que atiende a millones de clientes. Mucho de este framework, se basa en preguntarnos continuamente si lo que hacemos sirve para clientes exigentes, de los que manejan cualquier variable en magnitudes muy superiores a las habituales.

Pero empecemos por el principio de nuestro funnel. Si esta persona aterrizase en nuestra web buscando una solución a alguno de sus cuantiosos problemas: ¿entendería nuestra propuesta? Más aún: ¿podría fácilmente posicionarnos mentalmente delante de nuestros competidores cuando decida por quién empezará a probar?

Alguien que tiene millones de clientes, difícilmente se enfrenta a problemas nuevos más allá de la gestión de volumen. Tenemos que suponer que ya ha probado otros productos como el nuestro y no está satisfecho. Vamos, que es un experto en su problema y un gran conocedor de nuestro mercado. Por tanto, nos vamos a prohibir subir a la web contenido «barato», y vamos a explicar las características de nuestro producto en detalle.  O incluso colgar el manual completo. Y capturas en alta resolución. Y multitud de vídeos de ejemplo. Todo lo necesario para satisfacer las dudas de un experto en nuestro mercado, y para que lo interiorice antes de usarlo. Como cuando el comercial te deja dentro del coche que te gusta con las puertas cerradas. Algo que marque la diferencia para que pueda decidir si «hacemos lo que busca» o por el contrario «hacemos exactamente lo que busca».  Nótese el «por el contrario» de la frase anterior.

¿Y a la hora de probarlo? ¿Vamos a poner nuestro teléfono en la web, confiando en que la gente con más éxito es la que más llama? ¿O vamos a decirle a alguien tan ocupado que nos rellene un formulario (más orientado a nuestra segmentación comercial que a conocer sus problemas) para que uno de nuestros SDRs le contacte en unos días por email adjuntando un enlace a Calendly para una demo como proceso de evaluación previo a dejarle tocar nuestro producto? (Sí, es una frase larga sin comas, para remarcar lo absurdo de la misma). Pues que queréis que os diga… good luck with that. Mejor que empiece a probarlo con la mínima fricción posible, y pudiendo probar el mayor número de características posibles. O todas. Esa gente que esconde características durante el trial tiene un problema grave. De entrada, parecen tener miedo de que alguien pruebe alguna de las del plan más caro,  le guste, y se convenza para pagarla desde el primer momento… Hasta que aprendan que hay miedos que se superan con un despido.

Y ya que hablamos de pagar, ¿en base a qué le vamos a facturar nuestro servicio?  Ya dejaremos las negociaciones y los descuentos para cuando esté decidido. Pero vamos a lo importante: ¿estamos relacionando la variable principal de nuestro modelo de precios con el principal problema que intenta resolver? ¿Le va a ser sencillo introducirnos en sus márgenes? ¿Y se lo estamos explicando claramente sin necesidad de hacerle sacar una calculadora con RPN?  (Off-topic: si has utilizado una calculadora con RPN corre a vacunarte).

Aunque igual hemos corrido mucho empezando a pensar en el momento del pago. Así que retrocedamos a su primera experiencia con nosotros: ¿qué le está diciendo nuestra interfaz? ¿Que muchos procesos los va a tener que realizar moviendo una mano encima de un ratón? Pues vamos a tener complicado convencerlo. ¿Tenemos una interfaz pensada para las necesidades de este tipo de clientes, que trabajan con magnitudes no habituales? ¿Le vamos a obligar a que abandone la forma en la que trabaja habitualmente para venir a nuestra interfaz? ¿No podríamos simplemente enriquecer el entorno que ya usa? O ya que nos ponemos a darle vueltas a la interfaz: ¿es nuestra UI a propósito una sencilla capa sobre una API de la que somos también consumidores? ¿Puede automatizar cualquier tarea con pleno acceso a la API, o somos tan cutres de tener excepciones no documentadas que le hagan volver al ratón y a ciscarse en nosotros? ¿Puede batchear múltiples operaciones en cada petición? ¿Qué mensajes de error le está dando la API para ayudarle en sus primeros momentos? ¿Enlazamos en ellos a documentación detallada que resuelva todo tipo de dudas a clientes tan exigentes y ocupados? ¿Tenemos en esa documentación un sandbox para facilitarle todavía más que tenga una buena experiencia con nosotros?

Y ya que estamos hablando de que use nuestra API, pensemos también en que la tendrán que usar los servicios sobre los que se sustenta su imperio. Algunos de esos servicios estarán a la última moda, y otros no. O bajando a la tierra, dependiendo del tipo de cliente igual es más necesario generarle un XML que un JSON. O un CSV si me apuras. Y esos servicios, ¿los podremos actualizar cada vez que haya algún cambio definido en nuestra plataforma? ¿O van a tener qué hacernos polling para millones de registros continuamente? Si confían en que les avisemos para cada C_UD, ¿hemos probado que seamos fiables para sus magnitudes? ¿Qué SLA podríamos garantizar?

Y ya que estamos en las tripas de nuestro producto: ¿cómo va a controlar el estado del mismo? ¿Abriendo un dashboard? (Pun intended). ¿Cómo reportamos información? ¿Y con qué detalle? Porque ya os digo yo que lo de avisar de algunas cosas por email, probablemente no funcione. ¿Qué alertas, necesarias para alguien tan ocupado y exigente, vamos a enviar? ¿Qué threshold las define? ¿Se va actualizando?

Y acabando con las tripas, hablemos de sus datos y los nuestros mezclados. ¿Les estamos garantizando que seguimos todo el compliance necesario y que sus datos están mejor cuidados que nuestros hijos? ¿Tenemos unos contratos claros al respecto, que no le hagan dudar de que podríamos enfangar su exit? ¿Y documentación pública sobre nuestros procesos de seguridad? ¿Qué nivel de audit-logging ofrecemos?

Podríamos seguir divagando sobre cualquier otro aspecto o proceso de nuestro producto. Pero si os dais cuenta, todo se resume en una serie de buenos y obvios consejos que apenas nadie cumple:

• Pon la máxima información posible en tu web.
• Elimina toda fricción para poner el producto en manos del cliente.
• Marca un precio relacionado con el problema que solucionas.
• Desarrolla una API como principal interfaz en la que tú seas el principal cliente.
• Intégrate en los servicios y procesos existentes en vez de confiar en que los adapten a tu incapacidad.
• Elimina toda ambigüedad en tus contratos.
• Muestra que eres confiable tanto a nivel técnico como de seguridad.

Hay un consejo que se ha ido repitiendo entre generaciones de desarrolladores que tiene todo el sentido del mundo: always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Tras leer esta bonilista, espero que todos los que desarrolláis productos para empresas penséis algo parecido: «trabaja para que salga por la puerta sólo aquello que satisfaría al cliente más exigente del mundo». El del ratio del billón de dólares.

Este texto se publicó originalmente en la Bonilista, la lista de correo de noticias tecnológicas relevantes para personas importantes. Si desea suscribirse y leerlo antes que nadie, puede hacerlo aquí ¡es bastante gratis!

---

---

---