En Tinybird empezamos al revés que muchas empresas de producto: por la parte de monetizar. Antes de meternos 100% a desarrollar producto y luego ir viendo (pivotar lo llaman) decidimos empezar facturando con un producto muy pequeño y haciendo servicios profesionales.
El tema de servicios profesionales es un tema un pelín tabú, ya sabes, la métrica estrella de cualquier SaaS B2B es el MRR (la gallina que entra de forma recurrente al mes) y claro, los servicios profesionales no son, en teoría, recurrentes y tampoco escalan bien. Bien en el sentido de que necesitan personas, y somos caros y tenemos sentimientos, cosa que una máquina en amazon no. Por suerte nuestros clientes son personas y prefieren a alguien humano del otro lado.
Pero la realidad es que la mayoría de productos tienen una parte de servicios profesionales y son necesarios para cerrar clientes que paguen pasta. Hay muchas razones, la más importante es que hemos idealizado tanto las empresas de producto, gracias a esos blog post de americanos vendiendonos el mejor humo, que hemos perdido el norte y nos hemos pasado de vendernos a nosotros mismos.
Pero el troleo, que de verdad me apetece, no es para este post, ahora vengo a hablar de como organizamos internamente la gestión de estos servicios. Sí, es un post sin historia, símplemente te explico aquí lo que hacemos por si te sirve de algo en tu empresa. También lo escribo para mi yo pasado (y futuro, como todo lo que uno escribe), me hubiese gustado que alguien me explicase esto hace 10 años.
Somos una empresa remota, así que todo el proceso intenta ser lo más asíncrono posible. Sería gilipollas si dijese que es 100% asíncrono, pero sin duda molaría mucho más. Por otro lado, toda la gente en servicios profesionales son desarrolladores, nada de “perfiles más baratos”, “más de negocio” o “recursos intercambiables”.
Ahí va, tenemos:
Un proyecto en basecamp por cada uno de los clientes. A veces no son clientes y son simples (y muchas veces cortas) pruebas de concepto. Hacemos pruebas de concepto para ver si el producto resuelve tu problema, todavía no somos confluent y todo mundo usa nuestro producto aunque no lo necesite. Da igual. Nosotros usamos basecamp porque nos acerca un poco al sueño de vivir en La Zagaleta y tener vehículos prohibitivos en el garaje, pero cualquier cosa que tenga una especie de foro (guiño al IT de los 90) donde la información se divida por temas y no permita escribir más de 1 vez por minuto, va que bufa. Es decir, no te dispares en el pie con un chat por proyecto. Di no al chat.
Cada proyecto tiene asignadas dos personas, la que manda y el telonero. La que manda lleva la voz cantante, el telonero está para ayudar y por si el primero falla (vacaciones, enfermedad, personas a cargo…). Esta persona actualiza un hilo “worklog” cada vez que hay una interacción. Todo el mundo recibe notificaciones cuando hay cambios, puedes o no leerlas. A veces las lees de pasada, pero cuando lees de pasada la misma cosa 200 veces al final queda y cuando tienes que priorizar problemas todo es mucho más fácil. Así nos enseñaron las tablas de multiplicar (para los milenials: son como una minicalculadora, la que va en el móvil, pero en tu cabeza) y es verdad que fue un peñazo, pero ocho por cuatro son treinta y dos.
Cuando hay eventos o temas importantes, que se salen fuera del “worklog” usamos hilos específicos para comentar. Un problema grave, una solución que creemos que puede ir a producto, un evento específico. En general el truco es escribir lo que pasa, sin más.
Una vez a la semana hacemos una reunión de proyectos. En un Google Doc pone la fecha y se enumeran los proyectos actuales con los links a los últimos updates ANTES de llegar a la reunión. Normalmente cuando llegamos todo el mundo ya sabe que ha pasado porque han leído los updates, así que, aunque refresquemos la memoria, no suele haber dudas. Además, incluímos los proyectos nuevos, comentamos de que van, damos contexto y decidimos la persona que manda y el telonero. Se abre el proyecto de basecamp y se deja una descripción de lo que hay que hacer.
Estas reuniones la mayor parte de las veces son de coordinación técnica-negocio, es decir, siempre hay cosas que hay que negociar, decisiones que pueden afectar para cerrar un cliente, quizá hay que dar un toque a alguno para ver qué tal lo llevan…
Si hay algo que necesita tiempo especial hacemos reunión específica sobre ello previa actualización en su correspondiente proyecto.
Nada nuevo bajo el sol, seguramente la mayor parte de empresas de consultoría tengan un proceso mucho más depurado y haya herramientas maravillosas para este tema, pero la clave está en no olvidar que los servicios profesionales en empresas de producto también necesitan organización y procesos, especialmente 100% remoto.