Prólogo

Un prólogo no deja de ser una lista de excusas y explicaciones por adelantado, que usas para protegerte de las críticas, especialmente las tuyas. Así que, si quieres, te lo puedes saltar.

Perdona?

Como últimamente oigo hablar mucho de FDE o “Forward Deployed Engineer” y la mayoría de la gente que lo menciona no sabe ni por dónde le viene el aire, no porque sean tontos, que puede que también, sino porque no han tenido contacto real con el tema. Voy a hacer una aproximación -la mía, claro- a qué significa un equipo de este tipo, porqué se monta, cómo se gestiona, cuándo tiene sentido, cómo se contrata, cómo se entrena y de paso vamos a explicar el porqué la mayoría de tópicos son una gilipollez.

Pero si te tienes que quedar con una cosa es: los FDE son útiles, tienen sentido y deberías valorar tener un equipo en tu empresa de producto, especialmente si tu ticket es alto.

Para quién es esto

Esto en realidad es para fundadores o gente montando estos equipos, es decir, empresas B2B, que vengan a empresas relativamente grandes (aunque no necesariamente) con productos que requieren cierta integración.

Pero si quieres o tienes un rol de este tipo creo que puede ser de ayuda entender cómo otros lo hacen. Esto ayuda, da igual de que hablemos.

Pero por qué?

Soy el fundador de una startup B2B (Tinybird, unos 70 kilos de financiación, decenas de M en ARR), desarrollamos un producto técnico, la empresa y el producto lo montamos partiendo de un equipo de FDE (no existía el término, pero da igual) porque era una buena forma de que tus clientes te paguen el research de tu producto a la vez que ellos recibían ayuda. Vamos, lo que son los negocios.

El equipo sigue activo después de 8 años y no sólo ayuda a clientes en cosas específicas, sino que también forma parte del equipo de soporte. Mejor que contarte yo si lo hacen bien o mal, que los que reciben ayuda lo hagan por mi.

Creo que no hay mucha gente con experiencia real y mucho menos contándolo, así que he ahí la razón de este documento.

Qué narices hace un equipo de FDE

Pequeña introducción para gente que no hace B2B

Para tí, que acabas de leer B2B y no sabes por donde te vienen, te diré que cuando creas un producto y vendes a empresas relativamente grandes y/o avanzadas, normalmente necesitan ayuda. Algunas de ellas porque son unos paquetes, otras porque políticamente no son capaces de ejecutar con sus equipos y otras, los que más interesan, son los que te necesitan por tus capacidades. Cuando estás en B2C o incluso B2B con ticket pequeño, tú lanzas el producto y allí se las apañen, en B2B con ticket alto, no quieres dejarles solos.

En este último caso, y no seamos ilusos por amor de Dios, es muy difícil que tu software se acople perfectamente a los requisitos de una empresa, siempre hay recovecos, matices que necesitan ser adaptados. Así que tener un equipo que ayuda no es ninguna deshonra. Obviamente hay casos de empresas que son jodidas leyendas, por ejemplo, Datadog, donde no es necesario, los equipos del cliente ya se pegan ellos solitos para arreglar los problemas, pero aún así siempre tienen gente técnica ayudando.

Qué es un FDE y cómo se diferencia de un consultor con traje de 50 euros la hora.

Creo que la mejor explicación -indirecta, eso sí- del tema es este, buenísimo, artículo de un ex Palantir, que son los amigos que acuñaron el término. Por ser claro, lo puedes llamar FDE o como te dé la gana, pero no deja de ser la definición de alguien que 1) sabe lo que hace 2) mete una pata en el cliente para entender su problema y solucionarlo y 3) se trae el conocimiento que puedes aplicar en tu casa.

En la consultoría tradicional se hace 1 y 2. Bueno, algunas consultoras hacen poco de 1 y solo lo de la pata de 2. Idealmente un FDE debería tener foco en 3. Un FDE debería poder volver del cliente e implementar lo necesario en tu producto, y esto es relativamente fácil si tu equipo es pequeño, muy complicado en una empresa grande.

Pero hay una forma mejor de definir el rol: la diferencia entre un consultor tradicional y un FDE (o así es como lo veo yo) es que el FDE tiene “skin in the game”, se queda hasta el final y asume responsabilidad. En Tinybird he visto a gente de mi equipo ponerse a gestionar el proyecto al cliente porque veían que no serían capaces de llegar a producción.

Cual es el objetivo del equipo

La forma en la que yo lo defino es sencilla pero a mi me ha resultado muy efectiva: tu objetivo es poner al cliente en producción lo antes posible.

He repetido esta frase unas mil veces por semana, pero es importante nunca perderse en otros temas como “facturar más”, “ayudarle técnicamente”… a veces la ayuda es directamente proponerle una solución que significa no usar tu producto.

Obviamente para hacer eso tienes que entender su problema y para poder entenderlo y resolverlo bien necesitas su contexto. La forma de tener contexto es preguntar, entender y volver a preguntar. Plantear una solución, probar, validar, volver a preguntar… y así continuamente. Da la casualidad que los desarrolladores son expertos en hacer eso. Pero de esto hablamos en el siguiente capítulo.

Así que si paras de leer aquí ya tienes la clave: no te líes con métricas, con objetivos secundarios absurdos, si tu cliente gana, tú ganas, en facturación, en retención, en relación con el cliente y todo eso son efectos de segundo orden.

Un detalle que no puede pasar desapercibido: cuando te metes en un cliente a resolver un problema a veces el problema no está bien definido y tienes que definirlo. No hay una forma más efectiva de aprender algo que tener que enfrentarte tú a la situación en primera persona. Es lo mismo que ver como alguien resuelve un problema de matemáticas o resolverlo tú, sabes de lo que hablo.

El equipo, qué pinta tiene que tener

Cualquier cosa que hagas, la clave es el equipo. Ed Catmull ya explicó esto en una frase mucho mejor que yo lo podría hacer:

There is an important principle here that may seem obvious, yet— in my experience— is not obvious at all. Getting the right people and the right chemistry is more important than getting the right idea.

La gente adecuada con la química adecuada, quédate con esto. Eso sí, lo que haces tiene que tener un mínimo de sentido, pero eso Catmull lo dio por hecho, pero somos Españoles, es mejor no confiarse.

En nuestro caso la premisa era: “la gente está trabajando con los datos como hace 15 años pero hay tecnología y hardware mucho mejor, podemos ayudarles a hacerlo mejor”. Esta premisa, después de 8 años, puedo decir que era acertada.

Quién?

Pues depende del tipo de producto, claro, ya te lo acabamos decir Ed y yo, pero por amor de Dios, mete gente que sepa lo que hace. No metas a manzanillos que solo saben mandar correos y tener a la gente caliente, no sirven de nada, necesitas gente capaz, con iniciativa. Esta gente es normalmente cara, no escatimes. Suelen ser ingenieros (de hecho la definición de FDE viene a ser esto)

Repito, no escatimes, cada euro invertido en esa gente tiene retorno. Mucha gente suele ahorrar en esto, en soporte y en cosas que no tienen un retorno claro, pero, en mi opinión, es un error.

En mi caso contrato ingenieros de backend. Sí, nuestra área era “data engineering”, pero los “data engineers” no eran más que gente que sabía usar 4 herramientas, así que optamos por gente con experiencia en software, con buena base. No tenían ni zorra de trabajar con el cliente pero da igual, la gente aprende.

Pero tienen que saber “navegar el cliente”

Me pongo malo cuando escucho que estos perfiles tienen que saber de negocio, navegar, politiquear. Mi experiencia me dice que cuando alguien sabe hacer eso, lo aprovecha y termina por “solucionar” temas manipulando (iba a poner una palabra más suave, pero para qué). Una persona que resuelve con hechos, con cierta iniciativa, es mucho mejor a la larga.

Puedes tener de esos que “navegan” pero esos te sirven como ayuda al FDE, luego explicaré cómo.

Así que olvida esto, las cosas se aprenden, en Tinybird he contratado a gente que hablaba mirando a los pies y han terminado trabajando -y gustándoles- con cliente.

Tiene que ser un equipo?

Podrían ser personas individuales, no? En el fondo es gente que trabaja con un cliente y ya. Pues seguramente, pero tiene sentido que haya un equipo o así lo he hecho yo.

Primero, como siempre, tiene que haber alguien azuzando. Habéis ido alguna vez a una oficina del gobierno a hacer algún trámite? Visteis a alguien que no esté atendiendo, simplemente estando pendiente de que el trabajo salga? alguien que cuando el funcionario te comente “este trámite es el modelo 405 y tienes que ir a otra oficina” diga “no, esto lo resolvemos”. Pues eso, necesitas a alguien que asegure que las cosas pasan.

Segundo, el equipo además tiene que preparar, concienzudamente, el onboarding, los procesos, tiene que organizar y dar información a producto, tiene que saber cuando poner presión para terminar algo, necesitas gente con la que validar propuestas, etc.

Qué y cómo lo hacen

Ayudan al cliente en las partes que no saben. No son un horas-hombre, son el recurso que sabe. En nuestro caso los FDE hacen de FDE y ayudan en pre venta, post venta, soporte, etc. Pero aquí solo voy a hablar de la parte de trabajo *dentro* del cliente.

Hay 3 patas bien definidas de trabajo, 1) con los clientes, obvio que diría un Gen Z, 2) interno, no tan obvio y 3) con producto, un 50% de obviedad.

1) El ciclo con el cliente es “relativamente” fácil:

• Aparece un cliente que tiene un “reto”, del tipo que sea, dentro de tu ámbito. No hagas consultoría de cosas que solo te dan dinero, aunque puedas hacerlas.
• Alguien del equipo evalúa si realmente hay “reto”: pueden pasar dos cosas, tal vez solo necesite 4 cosillas, corregir dirección y listo o haya realmente carne que cortar. Interesan los clientes donde hay magro, claro. Normalmente esto lo suele hacer alguien con experiencia, pero con unos básicos (hablaré en la parte de “training”) es suficiente.
• En la primera reunión, si es posible, al cliente ya se le piden “datos” para trabajar. Es decir, nada de “organizamos una siguiente reunión”, se va directamente al grano. Esto es MUY importante porque aquí ves si realmente te están mareando o tienen un problema. Obviamente empresas grandes te van a decir “NDA, blahblah” pero, cuando hay necesidad, los NDA vuelan.
• Se establece un canal de comunicación permanente y en tiempo real. Nosotros usamos Slack, cualquier sistema sirve, pero tiene que ser donde viva el cliente. Tienes que estar dentro.
• Se monta un documento donde pone “a dónde queremos llegar” y se usa en cada reunión con el cliente. Estoy asumiendo que es todo en remoto, claro, nada de poner gente en oficinas… qué somos, animales?
• Se hace un checkin semanal para ver dónde estamos. Estar encima del cliente es fundamental, hay que ser insistente. Por mucho que tengas procesos, herramientas, gente entrenada, hay que apretar. Esto vale para FDEs y para cualquier cosa que quieras que salga, por mucho que digan “los amigos del proceso”
• Si el FDE lo considera, se fuerza reunión. Ya, ya, sé que lo de las reuniones bla bla blahj, pero hay reuniones y reuniones. Unas son para los que no tienen ni puta idea aparezcan en escena o, éstas que yo te digo que son para hacer que se tomen decisiones. Esta gente no hace reuniones si no es necesario, no son comerciales malos.
• Una vez se está en producción o has solucionado el tema que nos atañe, se sigue, se monitoriza que todo vaya, bien y se sigue estando encima.

En la última parte del documento hablo de la gestión no tan técnica del asunto.

2) Internamente, es decir, qué trabajo hace el equipo como equipo:

• Cada semana se repasan los clientes importantes, los no tan importantes pero con potencial y los de mantenimiento.
• Se recogen todos problemas y features de producto que están siendo un obstáculo. No se pasan a producto inmediatamente.
• Se revisa todo lo nuevo de producto y se mira si algún cliente lo puede aprovechar en sus casos de uso. A veces directamente se les pasa una prueba con sus propios datos (en nuestro caso). Recordad que eres alguien dentro de sus proyectos, no tienes que pedir permiso.

3) Con producto:

• Si es posible los mismos FDE son además los que hacen el producto. Raro pero se puede hacer cuando el producto está empezando. Puede que hagas overfitting de la solución, pero mejor eso que castillos en el aire.
• La persona que lidera el equipo está en las reuniones y checkins de producto. Es el piloto de pruebas. Si un FDE tiene que meterse a hablar con product managers o el rol de turno, se hace. Si se tiene que coger el PM y llevárselo de la oreja al cliente, se hace. El FDE es el tacto del equipo de producto (especialmente cuando las cosas queman)
• Se trackean los problemas y cuando se solucionan se informa al cliente “tu movida ya está solucionada”. No hay mejor estrategia de retención que ver se preocupan por ti (dime si no, qué haces en casa de tu madre a los 30)
• Se da la cara por el producto. Aquí no es un “producto dice que no puede”. No hay cosa más patética que usar a compañeros como palanca para negociar. Es patético, no lo hagas, elige dormir bien.

La rotación

Un punto importante es que la gente se cansa. La IA no, pero la gente sí, así que conviene que 1) estén en más de un cliente a la vez y 2) cambian de cliente cada cierto tiempo.

Idealmente un FDE debe pasar por producto, pero seamos sinceros, no es trivial mover a alguien tan fácil y una vez llegas a producto te acomodas en el calor de la protección de tus product managers, engineering managers, soporte… en los mundos de yupi donde los problemas son tickets en Linear y no situaciones donde tienes que dar la cara.

Otra forma buena de descansar es trabajar en algún reto complicado. Normalmente los clientes piden cosas absurdas, no pasa nada, es normal, yo lo hago a menudo y que a priori parecen imposibles. Esos retos en nuestro caso son del tipo “hacer este tipo de query sobre 10 billones de registros en menos de 100ms” y requieren meterse muy abajo. Este research es oro puro, mantiene al equipo despierto, ayuda a subir el nivel y consolidas los fundamentos. Es caro, pero más caro es tener un equipo desmotivado.

Para terminar, pero no menos importante (y repitiéndome)

Si crees que el objetivo de un equipo de este tipo tiene que ser maximizar facturación por cliente es mejor que cierres esta web y te vayas al rincón de pensar. Esto lo llaman los que ”saben” “customer success” y es la peste absoluta del sector. No, tu objetivo, siempre, es que los problemas se solucionen lo antes y lo mejor posible. El resto son gilipolleces o cosas que vendrán con tu buen trabajo (por ejemplo, el dinero).

Hiring y onboarding

Podrías pensar que necesitas a gente con experiencia en cliente o consultores o unicornios que sepan de tecnología y además tratar con personas, vestir bien, carisma, presencia, alto, guapo, que sea romántico pero firme…

No, seguramente tengas que contratar lo que tu cliente necesite. Te pongo un ejemplo, en nuestro caso tratamos con desarrolladores y esa gente detecta el bullshit a 200 kilómetros, no confían en nadie que no demuestre que saben lo que hacen y, normalmente, tienen una forma y unos hábitos de comunicación muy particulares. Si metes a un encorbatado le van a reventar en media reunión y habrás perdido toda oportunidad.

Ya pero tienen que tener “don de gentes”

Tienes que tener un mínimo de respeto, educación y tener claro lo que quieres hacer. No hace falta ser un trilero, hay que saber reglas básicas, que comentaré en la siguiente sección de “trabajo con el cliente”.

En Tinybird casi nadie de los que contratamos con este perfil tenían experiencia con “cliente”, eso sí, sabían lo que hacían, eso es lo importante. Dicho esto, yo he estado al frente de este equipo, he hablado con cientos de clientes y mi personalidad no es especialmente amigable -como puedes intuir leyendo este documento- la política no es lo mío y no sé leer las dinámicas de un grupo de personas.

Hiring

No creo que diste mucho de lo que buscas en un ingeniero de producto/backend/loquesea pero yo pongo MUCHO -muchísimo- foco en la forma de descubrir lo desconocido.

El proceso es el siguiente: propongo un ejercicio técnico MUY abierto pero sencillísimo (por aquí(*) tienes un ejemplo). Una vez veo la aproximación en las preguntas posteriores juego a cambiar las reglas todo el rato para ver cual es la forma de plantear los problemas.

En general el criterio de selección es sencillo: si se pone a resolver sin preguntar, mala señal, si pregunta, plantea hipótesis, busca entender, aclarar y acotar el problema, ese es tu perfil. Bonus points si además es técnicamente solvente, claro.

Un detalle importante sobre el hiring, nunca termina y tampoco es algo que hagas de vez en cuando. Tienes que estar hablando de lo que haces, tienes que ser atractivo para la gente para que cuando lances la oferta ya tengas gente buena, interesada. Esto es tan fácil como publicar periódicamente cosas útiles, cosa que casi nadie hace porque le dejan esta tarea a gente de marketing que no tiene ni zorra idea de lo que escriben (por lo general).

Por último, el hiring es un tetris: tienes que buscar la pieza correcta en cada momento, a veces el palo largo viene bien, otras veces no. El balance es la clave.

(*) Si lees el post, verás que prohibí usar chatGPT. Más tarde lo haría obligatorio.

Onboarding

Mucho más importante que el hiring, es el onboarding. Un buen onboarding te puede arreglar un mal hire (y estropear uno bueno). Los puntos fundamentales de un onboarding tienen que ser.

• Enseñar los fundamentos. No hay que liarse a explicar detalles, tienes que machacar los básicos unas 200 veces. Tienes que saber cuales son los fundamentos de tu negocio, claro.
• Que entre bien en el equipo. Como sea un sobrao o caiga mal, ya puedes darte por jodido. Y para esto hay muchas maneras, pero el roce hace el cariño y el “manager” o quien quiera que mande debe estar ahí metiéndolo, poquito a poco, en el equipo. Es el que lubrica, lima asperezas y hace esa función social de introducir a la persona a los rituales. La parte social de mantener el equipo con confianza, sin malos rollos es vital. Yo uso el humor y las bromas constantemente, incluso cuando la liamos parda. Seguro que tú tienes otra técnica, usa lo que te dé la gana, pero es tu responsabilidad hacer que alguien caiga de pie.

En Tinybird uso técnicas milenarias, a nadie se le habrían ocurrido:

• Tengo grabado un curso con los básicos que *tienen* que ver. Son fundamentos, nada que ver con la empresa, ni el producto ni cristo que lo fundó. Cosas muy muy básicas e iterar sobre ellas, mil veces. De hecho, este contenido lo publicamos y sirve como herramienta de marketing y para el hiring continuo que comentaba antes.

• Una serie de ejercicios reales donde iteramos sobre los fundamentos, ya con el producto. Obviamente hay una persona que se encarga de seguir, preguntar, explicar los errores y poner ejercicios para hacer hincapié en las cosas que no se entendieron. También solía poner problemas complicados de resolver para que no se vengan arriba (*).
• Poco a poco ir entrando en algún cliente, siempre de la mano de otro FDE. Normalmente suelen ser clientes más pequeños, donde sea más fácil entender el contexto y perder el miedo a preguntar o liarla.
• Al mismo tiempo esa gente tiene que escribir lo que aprende, a diario, así generan un hábito de escritura que servirá para documentar y que los demás aprendan (incluídos los LLM, claro). Despreciamos el valor de saber explicar las cosas por escrito y lo bueno que es documentar lo que uno hace. Mucho del conocimiento adquirido del equipo, lo que le ha hecho mejor, son los posts internos explicando cómo han resuelto cosas al cliente.
• Por último, el último truco es “echar a los leones” que viene a ser soltarles en algún marrón para que se busquen la vida. Mano de santo.

Firing

A nadie le gusta hablar de despedir porque culturalmente es algo que duele. Es normal, si tu país es un sitio donde la mayoría de trabajos son poco cualificados y el objetivo vital es tener trabajo fijo (siendo el funcionariado el monstruo final), es normal que sea así. Por suerte en nuestro sector si te echan de un sitio, al día siguiente estás haciendo 4 entrevistas. Sigue doliendo, pero es drama, no hay sangre.

Aclarado lo anterior, puedes despedir por que no esté a la altura, no encaje bien en el equipo o lo que sea, pero lo que NUNCA puedes permitir es que un cliente no esté bien atendido o haya “excusas”. Es un negocio de confianza, es el básico que no puedes perder. Del mismo modo, si eres FDE y tu jefe te pide que mientas, vete haciendo backup del correo electrónico y abriendo linkedin.

-–

(*) Como manager hay dos cosas importantes que suelo hacer:

1) Cuando mi hija me viene con los ejercicios de sumas de números de 3 cifras para que se los corrija, muchas veces le digo “hay una suma que está mal” sin haber mirado ni una sola cuenta. Esto dispara dos cosas, una de ellas es que aprende a asegurarse que el trabajo está bien hecho y la segunda, a pensar que no siempre “el jefe” tiene la razón, que a veces se equivoca, pero tienes que saber confrontarlo. El “pensamiento crítico” va a ser el conocimiento estrella de las siguientes décadas (con la IA de sabelotodo). Con los empleados funciona igual, piensan que no tienes razón pero no te lo suelen decir.
2) A la gente hay que ponerle siempre objetivos un poco más allá de lo esperado (por ti y por ellos). Si alguien tiene capacidad pero no lo pruebas, nunca lo sabrás. Además, durante el proceso de onboarding, pone las expectativas más altas, pero siendo aún un juego.

El trabajo, no técnico, con el cliente

No todo el monte es orégano ni todo el trabajo es técnico, hay otros temas importantes que hacer con el cliente, especialmente acordar cosas, dar visibilidad, poner límites y gestionar la relación con los que mandan.

Aquí es donde suele entrar la figura de una persona de negocio, ya sea un Account Executive, un fundador, el CEO, un CUSTOMER SUCCESS MANAGER KEY ACCOUNT ENTERPRISE SENIOR o como Dios quiera que se llamen (yo los llamo manzanillos, con todo el cariño), la parte importante es que esta persona es la que se encarga de marcar el paso de la relación, poner límites, hablar de dinero y ser el “poli malo”.

NUNCA, bajo ningún concepto el manzanillo se mete a pelear temas técnicos. Por dos razones, primero, la vas a liar y vas a perder puntos con los equipos técnicos y segundo, es mejor mantener una línea entre el trabajo operativo/técnico y la gestión del cliente. Piensa que hay dos “tracks”, cada uno a los suyo. Lo habitual es que llegue un punto donde el FDE y la persona de negocio con una mirada (por google meet, eso sí) sepan cuando uno tiene que dejar al otro. Si eres fundador puedes hacer lo que te de la gana y reventar el deal, para eso te pagas (es broma, pero no es mentira).

Arrancando el proyecto

Como digo, el trabajo con un cliente empieza siempre hablando del problema que hay que resolver y con toda la prisa del mundo. Pide accesos, datos, contacto y todo lo necesario para descubrir cosas cuanto antes. Este trabajo lo hace el caraboli (o sea el FDE), no el manzanillo.

Eso sí, es importante que haya expectativas claras, de tiempo, dedicación, dinero y límites. Es decir, esto cuesta tanto, vas a hablar con fulano y mengano, vas a tener acceso a esta persona con un SLA de respuesta de tanto, necesitamos esto y aquello y esto cuesta tanto al mes (que por supuesto se intenta meter como parte de ARR para que el AE cobre más comisión, faltaría más)

La parte más comercial del asunto creo que tienes que ver como asignan el presupuesto tus clientes, pero hay diferentes fórmulas para cobrarlo:

• Como consultoría: es una buena forma para empresa grande porque tiene presupuesto aprobado normalmente y están acostumbrados. Te das de alta en alguna plataforma lamentable y listo.
• Como soporte premium. El problema es que Amazon, Google y otros tantos dan soporte premium a una pasta que es una absoluta basura. Digo basura con conocimiento de causa.
• Directamente como parte del contrato del producto, un 10% mandatory cuando es contrato enterprise a partir de $X.

En cualquier caso, como cualquier contrato, siempre limita horas, fechas e implicación (SLAs de respuesta, etc).

Puedes no cobrarlo y asumir que tendrás retorno, a veces funciona, especialmente si estás hasta arriba de millones porque has levantado una ronda totalmente sobrevalorada y donde unos miles al mes te dan igual.

No solo hay que hacerlo si no que lo parezca: las reuniones de negocio

Como decía, el track de negocio tiene otra tarea: que se vea lo que se hace, a veces no es trivial que se vea el impacto del trabajo que hace el FDE, así que cuando la persona “de negocio” se reuna, y tiene que hacerlo regularmente, con la persona “de negocio” del otro lado, lo primerito que se explica es “mira, esto es lo que hemos hecho”.

Obviamente esta reunión se prepara antes, el FDE + persona de negocio se juntan, revisan los reportes escritos por el FDE (de ahí la maravillosa cultura de documentar todo) y preparan:

• Qué hemos hecho y porqué. No vale con un resumen de un LLM, hay que tener el pulso del cliente, cosa que los LLMs no tienen. Hay que leer entre líneas de lo qué es lo que aprieta.
• Cuales son los siguientes pasos, blockers y todo lo habitual en una reunión de este tipo, no te voy a enseñar aquí a gestionar un proyecto.
• Otros temas de dinero, negocio. NUNCA, NUNCA mezcles a la gente técnica en estas conversaciones. El FDE está para solucionar, la persona de negocio está para cerrar y hablar de estas cosas. Si mezclas los dos temas empiezas a pensar en términos de dinero y, aunque está bien tener algo de info, al final terminas por asimilar que es el objetivo.
• Y por último, la pregunta del millón, de donde va a salir tu boyante NDR (la americanada que dice cuanto expandes a un cliente): “hay algún proyecto más en el que estéis trabajando?”. Normalmente las empresas trabajan en más cosas y si te resuena puedes preparar una propuesta proactiva para trabajar en ello. Muchas veces surge de forma natural, empiezan a trabajar en un proyecto y el FDE se entera. De hecho, como FDE tienes que tener las orejas super abiertas.

Cuando el proyecto termina

Los proyectos nunca terminan, se ralentizan, pero es importante que sigamos pendientes de cómo van las cosas. Puede ser semiautomático, en los checkins, con métricas, preguntando al equipo del cliente.

Además, si estás en una empresa de producto (si no qué sentido tiene tener FDEs, no?), sabes perfectamente si van a churnear (total o parcial) así que podrás hacer esas maravillosas proyecciones que tanto gustan a la plana mayor. Y si eres listo en vez de quedarte mirando a la proyección harás algo para salvar al cliente. Casi siempre se puede salvar.

Miscelánea

Las personas en los clientes van y vienen, tienes que estar atento a esto para ganarte la confianza de las personas nuevas. En realidad, si has hecho un buen trabajo hablará por si mismo, pero recuerda siempre que los humanos somos lo peor y a alguien le puedes caer mal. Si le caes mal, pues bueno, así es la vida, pero que no sea porque has hecho una mierda de trabajo.

El trabajo se factura, bien directamente, bien como horas de soporte premium, o tiene que haber un ROI clarísimo en forma de expansión. Esto es obvio pero a veces, especialmente en startup, es fácil dejarse llevar por el “bueno, ya hablaremos”. En mi opinión tienes que lanzarte un poco a la piscina y arriesgar, pero tienen que salir las cuentas al cabo de los meses. Si no, estarás trabajando a lo tonto.

Los clientes suelen acostumbrase a tener un trato increíblemente bueno y luego no quieren menos. De ahí el tema de cobrar y hacerse valer.

Despedida y cierre

Dejando a un lado que trabajar y resolver problemas es algo que obviamente va a dar dinero y te hace aprender, hay una parte que se nos olvida: resolver problemas es divertido y reconforta.

Muchos desarrolladores que nunca habían trabajado con cliente, una vez pasan a otros roles (normalmente en producto, quién mejor para hacer producto que quien lo ha estado peleando), lo echan de menos. No solo eso, tienen ya el hábito de trabajar con el cliente, capacidad de hacer las preguntas adecuadas, tienen soltura (me encanta esa palabra).

Algunas cosas malas

No todo el monte es orégano, algunos de los problemas que nos hemos encontrado:

• Demasiada dependencia del FDE para que el producto se quede
• La empresa final se apoya demasiado en tu FDE y espera cosas que no deberían
• Terminas dejando a un lado la parte de crecimiento orgánico del tu producto. Se te olvida que el self-service puede ser una buena vía.
• Es difícil tener la cultura de FDE y la de product led groth al mismo tiempo.
• El equipo de producto se acostumbra a que los problemas del producto los suple una persona
• Los FDE terminan quejándose porque el producto falla pero no atacan el problema
• No “escala”, es decir, para crecer necesitas más gente y la gente es lo peor.
• Bueno, creo que tendría para otro post de 4500 palabras, así que voy a parar aquí

Necesitas ayuda?

Apúntate a este curso por solo… que noooo.

Si has llegado hasta aquí, tienes una empresa de producto B2B, quieres montar un equipo o tienes uno pero tienes dudas, encantado de ayudar, escríbeme y hablamos. Gratis, yo no me dedico a esto, lo hago como forma de poner mi granito de arena en el ecosistema.