la aeropress es un invento yanki. no lo voy a googlear, no tengo ninguna duda. es un tubo de plástico que va encima de la taza y te permite hacer café para una sola persona. no tengo ninguna duda. la ritualidad de la aeropress es lo que más me gusta. pesar y moler los granos. calentar el agua a 95 grados. llenar la aeropress con 255 gramos de agua y esperar 3 minutos.
Publiqué esta nota inicialmente el 5 de Agosto de 2021. La dejo acá pq Medium ahora tiene paywall.
Quiero empezar por decir por qué escribo esto. Se me ocurren dos razones. La primera es que este tipo de notas me suelen parecer exageradas o poco honestas (ej. nunca te dicen números o qué tan doloroso fue el proceso). Me gustaría intentar no hacer lo mismo.
La segunda es que creo que todavía es raro para una empresa con founders en Argentina levantar USD 1M en una primera ronda sin conocer a nadie y casi sin tener producto. Por eso quiero contar cómo lo hicimos, porque no somos super personas y, como tal, creo que cualquiera lo puede hacer.
Voy a contar el proceso, cómo fue para nosotrxs y voy a tratar de contestar las dudas que yo tendría pero para cualquier otra me pueden escribir por twitter por DM (@keyserfaty).
Hace algo como 2 años atrás (Diciembre 2019) había dejado mi anterior startup (era CTO en ese momento) y tenía ganas de arrancar algo propio. Pensé algunas ideas y la que más me convenció fue la que dió nacimiento a Palabra: una app para automatizar emails que parezcan emails personales. (No voy a contar detalles de qué hace el producto porque me quiero enfocar en la parte de la inversión pero para más data pueden ir a palabra.io).
Estuve laburando sola codeando y vendiendo mientras todavía trabajaba full-time por unos 6 meses. La verdad es que mi laburo corpo nunca me gustó y un día decidí renunciar y empezar a laburar full-time en Palabra. Para hacerlo estuve viviendo de mis ahorros por un tiempo (casi por todo 2020, en realidad). Renuncié en Abril 2020.
Como vivo con mi novia y yo literalmente estaba comiendome mis ahorros mientras ella laburaba full-time me puse un deadline imaginario: si para Junio no conseguía plata de alguna forma tenía que volver a buscar laburo. Un mes después me aceptaron en una incubadora.
La primera incubadora en la que nos aceptaron fue Pioneer. Pioneer es una joya para gente en nuestra geografía porque está hecho para founders internacionales. Si bien no me dieron mucho (ser aceptadx no venía con plata) sí me dio la confianza de que la idea servía para algo.
Pioneer tenía un “demo day”, es decir, un día en el que le presentás tu startup a inversores. A mí me tocó presentar la mía a uno de los founders de Intercom. Recuerdo haber tenido muchísimo terror de que me preguntara cosas que no supiera responder pero la charla estuvo bien y después hasta intercambiamos un par de emails.
Quiero recordar que para este momento yo nunca había pasado ni cerca de una persona como “el co-founder de Intercom”. Todo en esto me parecía super fantástico y aterrador.
Cuestión que gracias al demo day un inversor conocido (Jason Calacanis) nos invitó a formar parte de su aceleradora. Esta aceleradora venía con algo más: $100.000 dólares y un programa de 3 meses.
Y ahora sobre el punto de esta nota. Para explicar cómo logramos hacer esto hay que arrancar por decir que Launch (el nombre de la aceleradora en la que estuvimos) tiene como foco ayudar a las empresas a levantar plata. Explico esto porque no siempre el foco de las aceleradoras es ese. Algunas se especializan en producto, otras en ventas, etc. El foco de esta es el fundraising.
Así que por eso ellos nos presentaban inversores. 30 inversores por semana para ser más específicos a los que le pitcheábamos nuestra startup. De ahí, si a alguien le interesaba tu idea se reunían con vos.
Levantar plata, dicen, es algo que hay que hacer del todo y no a medias. En mi experiencia cuando estás levantando plata siendo CEO no tenés tiempo ni energía para nada más. En mi época de intentar levantar plata me reuní con al menos 5 inversores por día todos los días por 2 o 3 meses.
Voy a volver a dar contexto: yo soy programadora. No disfruto particularmente de hablar con gente. Sí es verdad que me encanta hablar de nuestra empresa y toda la convicción del mundo cuando lo hago pero igual: el proceso fue agotador. En total debo haberme reunido con unos 100 o 150 inversores.
Reunirse con esa cantidad de inversores significa escuchar que tu idea y tu empresa y tu equipo no sirven para nada 5 veces por día. Realmente creo que hace falta mucha calma y mucha convicción para seguir haciéndolo y no hacer caso a lo que uno escucha. A veces veo a otras empresas empecinadas con un inversor que les dijo que no y la verdad es que no lo entiendo. Creo que levantar plata “is a numbers game”: hay que hablar con miles hasta que uno dice que sí. Y uno es todo lo que necesitás.
Dentro de todas las cosas que tuve que aprender a hacer un pitch deck fue una de ellas (edité ese deck casi todos los días en lo que duró el proceso) y tuve que aprender a contestar preguntas de inversor. No cambiaría ese proceso por nada. Nos hizo pensar en otro nivel. Nos llevó a repensar muchas cosas del negocio que no teníamos claro y a tener conversaciones super divertidas (en mi opinión) sobre estrategia. (Para esta altura, vale aclarar, en el equipo ya estaban mi co-founder Pau y Gus nuestro primer dev).
Uno de esos días de 5 reuniones por día tuve una a las 4 de la tarde que antes de que arranque te dan ganas de faltar (pero por suerte fui). La reunión era con una inversora que formaba parte de un fondo nuevo (eran ella y otra inversora más) y creo que para aquel entonces solo habían hecho una inversión más. Su “check-size” (o sea, cuánto nos podían dar) eran 30k. El número era super bajo (algunos otros te dan 500k de una) pero ella me cayó bien y seguimos charlando.
Algunas semanas después nos volvimos a juntar y después una vez más. Y después nos dice que tienen algunos amigos en otra firma que nos quieren conocer. Sus amigos en su otra firma eran 2048 (un fondo de inversión de Nueva York) y el inversor con el que me toca hablar es ingeniero. No sé si fue una cuestión de timing, del training que tenía yo ya para esa altura o si genuinamente nos entendimos pero la charla fue increíble y este fondo decidió invertir 400k así, de un día para otro. El proceso entre que dijeron que sí y nos hicieron una transferencia fue de 4 días máximo.
Más contexto: estas son personas con las que hablamos 2 o 3 veces. Nunca nos vimos la cara porque todas las conversaciones fueron por Zoom. Al día de hoy hay algunas cosas que no entiendo pero me alegran infinitamente. Son unos inversores increíbles.
En el mes siguiente esta firma nos ayudó a cerrar en cuestión de días el resto de la ronda (o sea, nos presentaron gente y esa gente nos presentó gente). Lo que en un momento eran miles de reuniones por día que no llegaban a nada se convirtió en miles de reuniones por día en las que todo el mundo decía que sí y quería participar de la ronda. Tuvimos que rechazar a algunos inversores al final.
Hubo un momento en el proceso, sobre todo cuando la primera firma dijo que sí, que tuve dudas sobre la parte “logística”. ¿Cómo recibir la plata? ¿Nos van a dar un contrato? ¿Nos hacen una transferencia y ya? Todo eso se fue resolviendo sobre la marcha. Seguramente algunas decisiones que tomamos en cuanto a papeles no fueran las mejores. No me arrepiento a haberlas tomado. Creo que nuestro foco como founders es nuestra startup y no los vericuetos legales de un SAFE. En nuestra próxima startup lo haremos mejor.
Mi conclusión es que levantar plata es posible, si es lo que te interesa hacer y hacerlo desde Argentina es posible, incluso sin producto (o con poco producto).
Hay algunas cosas que creo que hay que saber para poder hacerlo: hay que hablar inglés, sí, pero tampoco le tendría terror a eso. Después de la reunión número 100 sos la Enciclopedia Británica.
Otra cosa: hay que conocer gente, sí. Alguien te tiene que abrir la puerta. Pero las puertas están ahí para todo el mundo. Nada te limita a aplicar a una incubadora, que te acepten y pasar por un proceso como este. Tal vez lo mejor de este proceso, diría, es ese spreadsheet con los emails de 150 inversores que sé que se reunirían conmigo si algún día vuelvo a arrancar.
No hay que estar en Estados Unidos (al menos, no por ahora por covid) así que creo que es el momento ideal para intentar hacer esto.
Y tal vez la menos mencionada en esta nota: hay que entender el juego que estás jugando. Hay un lenguaje que hay que manejar y entender. No creo que sea posible hacer esto si tu cabeza no está en Silicon Valley, aunque geográficamente no estés ahí. Así que si eso es lo que te interesa, mandale.
Por último mis palabras a la Karen del pasado que pensaba que esto no era posible porque tal vez alguien así está leyendo: sí es posible. Todo lo que hay que hacer es sentarse y laburar. Fin.
encontré una lista de ideas para startups que escribí en 2019 cuando elegía la idea para palabra.
hay muchas ideas que me parecen divertidas (hay algunas que ya existen) pero mi sensación es que en ese momento no hubiera sabido cómo validar el modelo de negocios de esas startups pero hoy tal vez sí.
me gustaría hacer el ejercicio de pensar cómo validaría el PMF de cada una de ellas.
Webapp to let people rent a desk on a house to use as a co-working space
esta idea es compleja porque es un marketplace y la complejidad de un marketplace es que tiene dos lados y hay que ocuparse de los dos: generar oferta y generar demanda.
lo primero que haría sería validar el lado de la oferta. ¿hay personas dispuestas a alquilar sus escritorios? ¿hay normativa al rededor de esto (imagino que no)? pero validaría que sea algo que legalmente se pueda hacer (o al menos que no sea algo que no).
me da curiosidad también el pricing. del lado de la demanda ¿cuánto estaría dispuesta a pagar una persona? validaría esto contra el costo de un co-working tradicional y vería si hace sentido (¿termina valiendo lo mismo o es más caro?).
suponiendo que no levanto ningún redflag en ninguno de estos puntos mi primer goal sería conseguir un primer booking. para eso necesitaría al menos una persona dispuesta a alquilar un espacio que esté bien ambientado. sacaría muy buenas fotos del espacio. armaría una web sencilla (algo que pueda hacer con cursor/composer en 1/2 horas) que simule un marketplace pero donde el único escritorio que se pueda alquilar sea ese. haría publicidad en IG (reels posiblemente) y validaría conversiones a la web y pedidos de booking. mi goal sería conseguir 1 booking.
si existe un booking podría decir que el modelo de demanda está validado. supongo que los siguientes pasos serían analizar la competencia y el pricing más a detalle. no tengo claros los economics de un modelo tipo Airbnb pero investigaría eso e intentaría hacer un primer borrador de gasto/ingreso para entender qué pricing hace sentido y cuál no y sobre todo cuánto puedo permitirme invertir en marketing.
si todo esto se diera ok seguiría potenciando la oferta y pusheando más la demanda con ads en reels.
App that lets people upload a short podcast on any topic
esta idea me parece interesante porque es algo que me gustaría que exista pero no estoy segura de cómo empezaría. me gusta la idea porque es un TikTok de audio. me pregunto si existe una versión mínima de esta idea o más bien algo que la gente ya haga que se parezca a esto. por ejemplo: creo que podría empezar por agarrar buenos capítulos de podcasts y recortarlos y solo dejar 1 o 2 minutos de contenido que esté bueno. me gustaría evitar tener que hacer una app para validarlo porque hay un tiempo de desarrollo que es inevitable (aunque es cierto que este tiempo es mucho menor).
preferiría enfocarme en la calidad del contenido. me pregunto si podría validarlo enviando estos podcasts cortos por whatsapp como audios y medir la reacción de personas que conozco.
otra opción podría ser, en vez de hacer una app mobile, hacer una web simple que funcione muy bien en mobile que tenga una interacción parecida a la de tiktok (scroll, up and down para pasar al anterior/siguiente).
si hiciera esa web podría enfocarme en la parte de la distribution. cómo vender b2c es algo que me escapa un poco pero tengo algunas intuiciones: 1) me valdría de la distribución de otra plataforma (como tiktok y twitter). compartiría el contenido ahí para que lleve a la app 2) eliminaría barreras de entrada a la app (poder escuchar y compartir sin signup) 3) haría desde el momento 0 mecanismos de share (que se pueda compartir como audios de whatsapp, que al final cada audio diga que podés escuchar más de estos mini podcast en ‘www.tal’).
el éxito acá sería visitas a esta web y número de shares. también mediría si la gente vuelve.
hay algo de esta idea que me falta destrabar sobre por qué alguien la usaría. es entretenimiento? es un reemplazo a tiktok? un poco suena a esas ideas que suenan bien pero que en realidad no usaríamos.
app to pay someone to teach you something
esta idea es de las fáciles. marketplace de nuevo. el concepto sería ‘me gustaría aprender tal cosa, quién me lo enseña’. cargaría cientos de pedidos de este tipo (en este caso se puede simular la oferta) y validaría si existen personas dispuestas a ofertar un monto de plata para enseñarlo. haría ads en social media de nuevo o usaría twitter o ads de twitter. el success sería personas ofertando.
luego de eso validaría la oferta. si lo anterior funcionó debería tener flow de usuarios en la app. tendría desde el momento 0 la opción de cargar pedidos. el success que haría que le dedique más tiempo a esta idea sería 1 pedido de una persona real conectada con 1 oferta de una real.
haría lo mismo que en la primera idea para validar competencia, pricing etc. para todas las cosas que involucren programar tomaría shortcuts. no implementaría login, pagos, etc hasta muy validado el modelo. manejaría todo con forms y de manera manual hasta que eso pase.
me parece una de esas ideas con poca sustancia que creo que no podrían crecer en algo grande. pero puedo estar equivocada.
mobile app for motivation for female entrepreneurs
entiendo por qué la karen del pasado pensó esta idea pero creo que esto es más una comunidad que un business.
app to keep track of someone else’s tasks
creo que tenía un insight interesante para esta idea cuando la pensé pero hoy creería que la solución es un Linear.
display list of new features of a release to integrate into a site
esta idea me gusta. hay algunas soluciones que ya existen para esto. es un producto chico y sería una buena idea para una app bootstrapped. creo que es de esas apps que antes hubieran sido inmensas pero hoy son fáciles de programar. el mvp sería un formulario donde cargar una lista de features/bugs corregidos y un <script> que se pueda copiar/pegar en una app para mostrar el listado (ya sea en un desplegable en una notificación o como una lista). armar este mvp no debería tomar más de una semana.
pensando en la distribution mi primera intuición es hacer SEO. esto es un b2b después de todo y el usuario objetivo posiblemente sea un techlead o un PM que quiere mostrar esto en su app. posiblemente antes de empezar iría un paso atrás y hablaría con estas personas. sé que hay algunas empresas que usan apps como estas para mostrar el changelog pero no tengo claro en qué estadío están cuando lo empiezan a necesitar o si tienen algo en común. por ejemplo: los b2c tienen más tendencia a querer mostrar listado de features? hay alguna industria en b2b que valore más la velocidad de desarrollo y quiera mostrar esto? hay algo que esté roto en este proceso de querer compartir el changelog?
me puedo imaginar (porque lo vivo en el día a día) que el changelog es algo que toma trabajo armar. se puede simplificar de alguna forma? por ejemplo tomando la lista de últimos commits, parsearlos con AI y hacer con eso el changelog?
tampoco tengo claro quién sería el comprador de este producto. creo que es un TL o un PM pero no estoy segura. cuál es el incentivo a querer tener un changelog? qué problema tiene esa persona que se soluciona con un chanelog? visibilidad con los clientes o el equipo interno? presionar al equipo para que tengan releases más a menudo?
no programaría nada hasta tener esto en claro porque la solución puede verse de maneras muy diferentes dependiendo de la respuesta.
otra punta para investigar sería revisar a la competencia actual. ya existen herramientas así y deben resolver un pain claro. seguramente lo dicen en su sitio web. cuál es? si lo valido con un PM/TL se confirma que eso es un pain para ellos?
tool to integrate notifications to sites
creo que esta idea puede disparar para muchos lados. qué tipo de notificaciones? en apps o en sitios? creo que no la voy a explorar porque no tengo claro qué quería decir la karen del pasado.
tool to allow anyone to create an online course
no la voy a explorar porque es una mala idea. en 2020 nacieron miles de estas y murieron todas y ahora existen los LLMS.
job board for education
no estoy de segura de en qué consiste esta idea.
app that lets entrepreneurs manage their finances when they are just getting started
esta idea me gusta y voy a decir por qué: es específica. creo que hay una idea más grande detrás de esto (es finanzas para entrepreneurs en general? es una app sencilla para manejo de finanzas que empieza por entrepreneurs y después amplía a otros públicos?).
empezaría por listar problemas específicos que tienen los entrepreneurs con finanzas y creo que hay muchos sub-nichos en los que enfocarse. por ejemplo Latam entrepreneurs en US con una visa de trabajo. ese grupo tiene unos pains muy puntuales. otro es entrepreneur argentino que tiene toda su economía en US pero vive y paga impuestos en Argentina.
elegiría uno de estos sub-nichos y entendería hasta el final cuál es su pain más grande. cuál es la cosa que necesitan hacer sí o sí (por ley por ejemplo) y no pueden. tendría miles de entrevistas y prestaría atención a qué se repite. hay algo que todos resuelvan ya hoy de algún modo pero que no exista una solución buena para hacerlo? por ejemplo: 5 personas distintas mencionaron que resuelven TAL problema de 5 maneras diferentes (con un excel, con un externo, con una app). buscaría problemas para los que estas personas ya hayan encontrado una solución pero donde la solución sea insuficiente. le escaparía a los ‘deseos’ y falopas que se dicen en el aire pero que cuando les preguntas sobre ‘bueno, y cómo lo resolvés ahora’ la respuesta es que no hacen nada. eso no es un pain. hay que tener cuidado con esos.
si encuentro una cosa que todos tengan en común en mi call número 6 escucharía y después ofrecería esa solución a la persona. le diría que el pricing en X. (incluso sin tener ese producto). vería si está dispuesto a pagar. la única forma de validación es plata en el banco. no existen los ‘re interesante, contame cuando lo tengas. me re interesa, avisame más adelante’. si te interesa, si es un pain pagás por una solución.
si esto se da haría un producto chico, precioso que solo resuelva este problema y lo resuelva muy bien.
app that lets entrepreneurs see their conversion funnel and optimize it
no voy a explorar esta idea porque hice una empresa con ella (esto fue Palabra). si bien hoy sabría posiblemente cómo validarla me aburre el ejercicio de volverla a pensar.
a youtube for action cameras
estaba viviendo en tailandia cuando escribí esta lista. honestamente creo que es una idea malísima.
tool that let react native developers work on iOS and Android at the same time
acá hay un challenge técnico enorme que si se destraba se destraba un business inmenso. lamentablemente creo que antes de pensar en distribution en este caso hay que pensar cómo se vería una solución. hay que explorar la tecnología.
también hay que cuestionar el statement e ir al problema. creo que el problema es que las apps de RN se ven muy diferentes en ambos dispositivos. tal vez es esa la parte que se puede solucionar y eso resuelve el problema de fondo.
email marketing tool for early stage startups
palabra también fue esto. de hecho esta fue la idea que lo empezó todo! hoy existen buenas soluciones para esto. de nuevo, me aburre explorar cosas que ya pensé varios años.
ya escribí otras veces sobre la importancia de la velocidad y creo que a veces en tecnología le pedimos a los equipos de producto velocidad en el vacío. pensamos que la velocidad es un tema de orden o de voluntad pero lo cierto es que muchas veces la velocidad del equipo es resultado de decisiones técnicas que se tomaron en el pasado y revertirlo toma tiempo.
en esta nota me gustaría contar el proceso que vivimos en atlas para pasar de releases casi inexistentes a varios releases semanales (entre 4 y 5 releases por semana por las últimas 6 semanas). quiero contar mi diagnóstico de por qué cuando yo comencé a trabajar con este equipo no era posible hacer releases rápidos y por qué ahora sí y qué hicimos para llegar hasta acá.
todo lo que voy a contar a continuación fue un aprendizaje para mí. nunca había vivido un proceso así antes y no tenía un plan cuando comencé. tenía una idea clara de a dónde quería llegar y me fui guiando por intuiciones a lo largo del camino.
quiero contar este proceso para documentarlo y no olvidármelo y por que puede ser útil para otros. por esta razón esta nota va a ser larga y no busco que sea entretenida. mi plan es que sea un catálogo de todo lo que hicimos y todo lo que ahora sé que habría que hacer para llegar hasta acá.
me tomó un tiempo identificar por qué a nuestro equipo de producto le costaba hacer releases a producción. podía ver los síntomas de un equipo que tenía problemas (poca interacción, muchos bugs, solución reactiva de problemas, ningún roadmap o proyectos en progreso con prioridad bajísima) pero no entendía las causas.
estas son algunas las razones que ahora veo que causaban que los releases fueran lentos:
- codebase con mucho tech debt. nuestro equipo venía de muchos cambios de dirección en producto y negocio. esto sumado a velocidad de la mala (shortcuts por todas partes, funciones de 900 líneas), ausencia completa de tests y typescript hicieron que el codebase sea algo realmente inmantenible.
- modelo de datos no escalable. muchos meses de cambios de dirección y poca estrategia hicieron que el modelo de datos fuera igual de malo que el codebase. el problema de esto es que los datos que almacenábamos no eran confiables y había casos básicos para nuestro modelo de negocios que no era posible reflejar en el modelo de datos (todo era un parche; mucha info duplicada, inconsistente).
- un equipo muy desmotivado. creo que los dos puntos anteriores explican cómo se sentía el equipo en este momento. cualquier feature que quisiéramos sumar era muy traumático, el 80% del día era solucionar bugs (tampoco había un proceso claro para esto), había muy poca comunicación (literalmente muy pocos mensajes en slack) y mucha desconexión con el resto del equipo/con los equipos enfocados en el negocio.
- falta de estrategia. este sin duda es mi gran aprendizaje de este proceso y voy a hablar mucho sobre esto más adelante. en resumen no había una estrategia clara de producto ni a corto ni a mediano plazo. esto no era responsabilidad del equipo de producto. ahora sé que para poder crear una estrategia hay un norte que tiene que estar definido desde el negocio. los síntomas de que nos faltaba estrategia eran que el resto equipo nos pedía un roadmap que no existía o nos preguntábamos si necesitábamos un head de producto. creo que lo que faltaba en realidad eran un objetivo y estrategias claros para el producto.
los cuatro puntos que mencioné antes eran iguales de frustrantes para mí que para el equipo. tenía ganas de pensar en features nuevos pero me daba cuenta de que había que hacer mucho trabajo por atrás para llegar ahí. estas son algunas de las cosas que hicimos en los primeros meses para mejorar nuestra velocidad de release:
1. el equipo necesitaba un win. lo primero que hicimos fue un proyecto de cero: una app nueva para suppliers. el objetivo de esta app era claro: nuestro product designer venía de meses de diseñar pantallas que nadie programaba. nuestro equipo de front estaba agotado de agregarle parches a una aplicación que no daba para más. necesitábamos un blank canvas. una nueva app, una nueva librería de componentes, un proyecto que nos diera orgullo. también necesitábamos darle tiempo a backend para los cambios grandes que tenía que hacer. empezamos por acá y un par de semanas después tuvimos una app diseña y con front 100% implementado. esto fue una primera prueba de la velocidad que podía tener el equipo trabajando con mejores herramientas. este proyecto nunca tuvo integración de back y nunca vio la luz pero cumplimos ese objetivo y tuvimos una app con mejor diseño y mejor ux hecha 100% por este equipo.
mientras tanto el equipo de backend necesitaba cambiar algo para que pudiéramos hacer proyectos más ambiciosos.
2. necesitábamos rehacer nuestro modelo de datos. los problemas en el modelo de datos eran claros. mi indicador era que la información que estábamos almacenando era errónea y muchas veces contradictoria (i.e. dos queries distintas que deberían dar el mismo resultado daban resultados distintos). también era una intuición: mi sensación al ver las tablas de la db era que cada dev había agregado columnas para lo que necesitaba desarrollar sin tener en cuenta el todo (el resultado era mucha info duplicada inconsistente). cambiar el modelo de datos es un proyecto inmenso y creo que muchas cosas en este proyecto estuvieron mal. la primera es que no supimos recortar el scope. necesitábamos pensar un mejor modelo, implementarlo, migrar la data vieja y deployarlo. las 4 cosas eran extremendamente desafiantes y lamentablemente este proyecto duró 6 meses (habíamos planificado 1). los resultados fueron gigantes cuando estuvo terminado: ahora los datos reflejan la forma en que pensamos el modelo de negocios. nuestro modelo de datos soporta realmente los datos que tiene que almacenar, sin hotfixes, sin parches, sin columnas nuevas cada vez que no sabemos dónde va algo. (también tengo aprendizajes de las decisiones que tomamos: priorizamos que el modelo de datos fuera claro a la hora de la escritura pero nunca pensamos en la lectura).
3. necesitábamos más y mejor talento. este es el punto más sensible de esta nota pero quiero ser transparente. nuestro equipo tenía algunas personas fantásticas y algunas que no. para mí, una paracaidista total en este equipo, el desafío estaba en entender quién estaba de un lado y quién de otro. yo tiendo a pensar que cuando hay un problema con las personas las razones pueden ser dos: contexto (es decir: esta persona es brillante pero las condiciones en las que está hacen que no pueda brillar) o individuales (esta persona no trabaja bien por falta de seniority o agency). este equipo tenía muchos problemas de ‘contexto’ por eso para entender cómo trabajaban las personas de verdad mi solución fue darle a casi todos proyectos desde cero donde pudieran pensar y proponer como si no hubiera más nada. algunxs brillaron y para otros fue un infierno.
la parte feliz de este proceso para mí fue aprender a contratar. escribí sobre eso acá. con un equipo armado nos pusimos a trabajar en el próximo milestone.
3. era necesario reescribir de cero el backend. esto no fue una decisión obvia ni fácil. nuestro backend era lo que describí antes: un nido de ratas. funciones inmensas (900 líneas o más para hacer cosas muy simples), parches para resolver casos específicos en todas partes, 0% de test coverage, no usábamos typescript y no teníamos buenas maneras de hacer testing o qa. decidir reescribir el backend fue el resultado de preguntarnos qué tomaba más tiempo: que este equipo nuevo le dedicara tiempo a entender todo lo que ya estaba hecho o escribirlo de cero. nos inclinamos por lo segundo por pura suerte y fue una decisión super acertada. hoy nuestro backend tiene 100% de test coverage varios meses después de tenerlo productivo y la arquitectura es escalable (siempre hay problemas y cosas a mejorar pero estamos parados en un lugar muy diferente). hicimos esto de manera gradual y el tiempo que nos tomó esto vs. agregar tests y reescribir lo viejo finalmente fue claramente menor.
4. un proceso claro para reportar y corregir bugs. todo esto tenía que suceder en simultáneo con seguir operando en el día a día. eso significaba que íbamos a seguir teniendo bugs que resolver. recuerdo que en ese momento todo nuestro equipo no técnico estaba muy frustrado con el equipo de producto. estaban frustrados porque las cosas estaban rotas y el equipo era muy poco responsive. hay dos cosas que hicimos acá: la primera fue literalmente bajar de slack todos los pedidos que llegaban para los devs, ordenarlos en prioridad y solucionar de fondo los 5 que más aparecían. esto era importante porque si los devs seguían teniendo que ocupar el 90% de su tiempo en solucionar bugs no iban a poder trabajar en proyectos más grandes. la segunda cosa que hicimos fue poner devs on-call cada semana, rotativos. el goal de esto es que hubiera un owner claro cuando llegaba un pedido. creo que esto nos ordenó un poco pero este punto sigue siendo un dolor hoy en día y creo que todavía no aprendí cuál es el ideal de cómo hay que organizar el trabajo en features vs. bugs.
5. el equipo necesitaba expectativas claras y un career path. más allá de la motivación que te da trabajar en proyectos que te dan orgullo lo otro que es importante para mí es que los equipos tengan un norte claro. me parecía importante que este equipo supiera qué era lo que se esperaba de ellos a nivel técnico y a nivel de negocio: era importante que fueran devs de primer nivel en lo técnico y que estuvieran muy involucrados en decisiones de negocio. marcar las reglas de juego fue importante para dos cosas: poder tener un framework para analizar quiénes no entraban ahí y para poder establecer reglas claras para premiar a los que sí (en nuestro caso: performance reviews una vez al mes y oportunidades de moverse hacia adelante en la escalera cada 6 meses).
con todas estas cosas arriba y comenzando a dar algunos frutos llegó mi gran aprendizaje de este año. necesitábamos un/a (o unos/as) PMs aunque yo en ese momento todavía no lo sabía.
la idea de que el equipo necesitaba un/a PM nació de un lugar inesperado. cuando pasaron algunos meses y el equipo funcionaba de manera mucho más aceitada de repente tuvimos tiempo para pensar features. además veníamos de no tener releases hace mucho tiempo (porque estábamos haciendo mucho trabajo por atrás para que las cosas estuvieran bien). la idea de que necesitábamos un/a PM nació de la necesidad de pensar en qué queríamos hacer con el producto, es decir, cuál era la estrategia de producto.
quiero contar de donde vengo: programé durante 10 años y nunca jamás tuve una buena experiencia con un PM. en los equipos en los que yo estuve la PM era una persona que bajaba una lista de tareas sin ningún contexto y te pusheaba para que las termines en una fecha. yo me opuse durante toda la vida de Atlas a que tuviéramos PMs y creo que esto es porque no entendía la importancia de este rol.
la otra cosa que noté es que cuando no hay PMs alguien más hace ese trabajo igual. en nuestro caso eran los devs: planificando, estimando, etc. esto no está mal pero creo que no es el mejor uso de su tiempo. por otro lado aunque pueden planificar y estimar no conocen o no elaboran la estrategia así que igual falta un pedazo.
me convencí de que lo que nos faltaba era una PM escuchando el podcast de Lenny y porque me empecé a hacer una pregunta: hacia dónde quiero que vaya el producto y cómo hago que lleguemos ahí. investigando aprendí que un buen PM uno ambas cosas y se encarga de lo más importante de todo: la estrategia.
pensar en estrategia es de las cosas lindas que me ha dado este año. voy a definir a la estrategia de producto como creo que más se entiende: una estrategia es una serie de pasos consecutivos que si se cumplen nos permiten cumplir una meta.
el mejor ejemplo para mí son el objetivo y la estrategia de Tesla:
Goal: Tesla’s mission is to accelerate the world’s transition to sustainable energy
Strategy: Build a high-priced sports car → Use that revenue to build an affordable car → Use that revenue to build an even more affordable car → While doing so, also provide zero-emission electric power
el momento en que de verdad pivoteamos la forma de pensar producto en Atlas fue cuando dejamos de hacer cosas porque sí y ordenamos nuestros features e ideas detrás de un goal grande.
a raíz de esto empezamos a escribir documentos (i.e. PRDs) con 4 secciones: misión y visión del proyecto, estrategia y features. lo importante para mí de esto es que las cuatro secciones son consecutivas. la visión se desprende de la misión, la estrategia de la visión y los features son el resultado natural de ejecutar la estrategia.
podría escribir una nota entera sobre esta parte pero creo que el aprendizaje importante para compartir es que ordenamos qué hacer desde producto detrás de un objetivo claro y eso nos dio más orden y sentido.
después de muchos meses el equipo empezó a trabajar de forma más ordenada. todo lo que describí antes nos ayudó a recuperar la velocidad de releases y aunque ahora tenemos desafíos nuevos y la calma siempre está en peligro (porque los negocios crecen y nada es inmutable) hoy tenemos bases sobre las que podemos construir y recuperamos nuestra velocidad de release. hoy el equipo manda a producción entre 4 y 5 features nuevos (importantes) por semana.
no creo que haya un silver bullet en lo que respecta a trabajar con personas. los procesos son complejos y los aprendizajes de hoy seguramente no se puedan replicar mañana. lo importante para mí en esta nota es contar cómo mejoramos un proceso que se sentía muy caótico con la aclaración de que este proceso tomó muchos meses y en todas las cosas cometimos muchos errores.
espero que les sirva si están pasando por algo parecido y que recuerden que siempre hay luz al final del tunel :)
si tuviera qué buscar ideas para una nueva startup hoy partiría de dos lugares: problemas que experimenté de primera mano durante atlas y problemas que me interesan desde hace varios años a los que les hago seguimiento. pensar en ideas para startups es algo a lo que le dedico tiempo desde hace unos meses. me parece divertido el ejercicio mental de pensar en todas las aristas de una idea como si fuera a ejecutarlas. lo hice pensando en cómo haría un crm que compita con hubspot acá y en cómo haría un nuevo cliente de emails acá.
pensar en ideas para startups como un ejercicio intelectual me parece divertido porque me permite entender cuáles serían “buenas” ideas. me gustaría contar el framework que uso para encontrar ideas y para entender si funcionarían en esta nota.
como ya dije mi forma hoy es partiendo de dos lugares: problemas que experimenté de primera mano durante atlas y problemas que me interesan desde hace varios años a los que les hago seguimiento. voy a empezar por la primera.
creo que se habla poco de que tener una startup de alguna cosa, no importa qué, es un buen puntapie para pensar ideas para las siguientes. haciendo atlas hace 2 años trabajé en todos los roles: fui diseñadora y dev, equipo de sales, head of marketing. al trabajar en los problemas de una startup de primera mano se te ocurren muchas cosas que podrían ser mejores: productos insuficientes o demasiado genéricos, aplicaciones que son el standard para solucionar un problema pero que son un perno de usar. mi aprendizaje acá, y es algo que no sabía antes, es que es muy difícil pensar en ideas para startups en el aire y sin experiencia haciendo. me imagino que tener un trabajo corpo tal vez puede reemplazar esta experiencia también pero como nunca tuve uno no lo sabría decir. también supongo que no es necesario fundar una startup. con trabajar en una muy early stage y donde te den mucha autonomía tal vez es suficiente también.
hay algunas condiciones para que esto funcione: no es suficiente con tener un trabajo en una startup. es importante que la cultura de esa startup sea de ownership para que te permitan experimentar con herramientas y soluciones y también (y fundamentalmente) para que los problemas no vengan predigeridos con una solución ya dada. es importante que sea un espacio donde vos busques soluciones.
si conseguir un trabajo en una startup es difícil siempre está la opción de abrir una. esto puede parecer difícil pero hay muchas formas de comenzar. seguramente mi recomendación sería ir a una incubadora, recibir un poco de capital y usarlo para experimentar. pero tener una startup tampoco es suficiente: es importante que tu estilo de trabajo no sea hand-off sino los problemas de los que hablamos los va a enfrentar alguien más.
(digo que es difícil pensar en ideas para startups en el aire también porque estoy pensando en startups b2b. si quisiera hacer una startup b2c no sería necesario y podría usar mi propia experiencia para pensar soluciones.)
la segunda manera de pensar en ideas para startups que yo encontré es haciendo seguimiento a problemas que me interesan. algunos ejemplos: cuentas de banco internacionales para residentes de latam. otro: stripe para latam. ambos problemas han tenido varias soluciones a lo largo de los últimos años. con el paso del tiempo vi el rise and fall de muchas de estas.
mi aprendizaje acá es que como son problemas que me interesan le dedico tiempo a pensar cómo sería una buena solución. y como no es algo en lo que yo esté trabajando puedo mirar de lejos las soluciones de otros. esto podría generar un efecto de 2nd mover advantage si alguna vez quisiera explorar una solución en estos espacios. la ventaja de esto es que vi por mucho tiempo distintos approaches y qué salió mal. hasta el momento en que aparezca un único ganador en uno de estos espacios este sigue siendo un espacio en el que puede valer la pena meterse.
técnicamente cualquiera puede hacer lo mismo que yo vengo haciendo: hablar con founders de startups de espacios que me interesan, entender por qué eligieron el approach que eligieron, pensar (fundamentalmente pensar) en qué haría yo diferente. todo esto sumado a tener ese problema de primera mano. si estos dos problemas que menciono me importan es porque experimento los dos. tengo opiniones sobre cómo querría que fueran las soluciones a estos problemas. sé todas las cosas que se han probado y que han funcionado o no.
hay algo importante que se desprende de esto que estoy diciendo: cuando hablo de encontrar ideas no hablo de ideas de productos sino de problemas. acá estamos en la búsqueda de problemas. pueden ser problemas que tienen las empresas o que tienen los individuos pero en ningún caso hablamos de pensar en ideas para apps o de sus soluciones. siguiendo los ejemplos que dije antes con problemas me refiero a:
1) ‘quiero crear una startup para latam pero cada país tiene métodos de pagos distintos y toma mucho tiempo integrarme con todo’ (hay una idea subyacente también acá y es que para hacer una startup para latam hay que hacerla para todo latam, no es posible hacerlo para solo un país y de ahí la complejidad de gestionar pagos).
2) ‘el sistema bancario de mi país no es confiable y quiero ahorrar mi plata en una cuenta confiable en moneda dura. también quiero poder retirar esa plata a mi país’.
una manera de saber si el ejercicio que estamos haciendo funciona o no es poder formular qué problema encontramos de esta forma. es importante notar que la solución no importa. la solución al primer problema puede ser Yuno (integrador de plataformas de pagos de todos los países de Latam) o puede ser Pomelo (un emisor de tarjetas en 5 países de Latam). ambos solucionan este problema desde dos ángulos diferentes pero atacan el mismo. (y un detalle más: es notable quiénes son los founders de ambas startups. Yuno: ex-Rappi. muy probablemente experimentó de primera mano el problema que hoy resuelve. Pomelo: ex-Naraja-X. seguramente vivieron la complejidad de emitir tarjetas ellos mismos).
TDB
ayer leí que superhuman va a lanzar un nuevo feature que va a permitir que el inbox sea colaborativo. los clientes emails son algo en los que pienso y que me gusta desde Palabra y posiblemente desde antes. me pregunto desde hace algún tiempo qué es lo que le sigue al email como lo conocemos hoy.
me gustaría empezar por definir qué problemas tienen los clientes de emails y los emails como los conocemos hoy.
- 90% de los emails son basura. casi todo el contenido que recibo son suscripciones o cold emails. solo un porcentaje pequeño son emails dirigidos a mí y que tienen importancia y tienen que ser respondidos. supongo que podríamos clasificar a los emails entre: de venta y no de venta. otra categorización podría ser: for reply, not for reply.
- los emails que sí importan son difíciles de encontrar. cuando sí tengo un email que necesito responder este email se pierde en un marea de otras cosas que no importan.
- muchas cosas del formato son anticuadas. hay algo en el formato de escribir un mensaje como si fuera una carta, enviarlo, recibir respuesta y no poder tener métricas básicas out of the box como open y click rate es raro y anacrónico.
- el search no funciona. si quiero encontrar información que recibí alguna vez seguramente no lo logre. el AI puede ayudar con esto pero ninguno de los clientes de email que uso hoy en día hace un buen trabajo con esto.
creo que una solución básica de emails debería solucionar estos puntos: catalogar bien los emails out of the box (poder separarlos en for reply y not for reply), me tiene que permitir un search rápido e inteligente de los mensajes y tiene que mejorar el formato para que sea más parecido a un chat.
ver una demo de cómo se podría ver un inbox colaborativo me hizo pensar en dos cosas: 1) cómo ganaría si quisiera construir un cliente de emails y 2) todos los grupos de usuarios usan un cliente de emails del mismo modo? (siento que sales, mkt, cx, alguien usandolo para uso personal hacen usos completamente distintos de un cliente de emails). cómo construiría un cliente de emails solo para uno de estos grupos? cómo sería el cliente ideal de emails para sales?
algunos features que creo que necesita este grupo:
- inbox compartido con todo el equipo.
- integraciones con hubspot y salesforce.
- integración con múltiples casillas de emails (para poder hacer bien outbound).
- integración con linkedin y sales navigator.
- click and open rate out of the box.
- trackeo de si la otra parte abrió un archivo adjunto que le envié.
- integración con software para poder hacer llamadas.
- integración con calendly o similar para poder agendar llamadas.
- poder visualizar mi calendario más fácil (como superhuman pero bien).
- automatización de followups. poder automatizar una secuencia de emails hasta X goal.
hace algunos meses pienso en que algo que me impide tomar las mejores decisiones posibles en atlas son mis propios biases*. no hablo exclusivamente del bias al hacer contrataciones. pienso en decisiones de todo tipo: qué decido priorizar y qué no; quién creo que tiene un punto válido en una discusión; qué creo que es un buen output de un experimento; qué velocidad está bien y cuánto es muy lento/muy rápido.
lo que me preocupa sobre mis decisiones sobre estos temas es que las decisiones que nos trajeron hasta acá no son las mismas que nos van a llevar al siguiente paso (y esa idea también es un preconcepto). porque creo que mi forma de tomar decisiones tiene que evolucionar para poder crecer con atlas pienso seguido en las decisiones que tomo y por qué las tomo. específicamente pienso qué decidiría unx founder serie a o serie b que ya vio muchas de las cosas que yo estoy viendo ahora por primera vez. hay otra posibilidad que no estoy viendo? hay mejores preguntas que no se me ocurren hacer ahora?
me pregunto qué herramientas existen para combatir el bias. además de cuestionar las decisiones que tomo y por qué, existe algo más?
*preconceptos, prejuicios.
estoy haciendo una startup. hacer una startup es una función de tiempo vs. resultado. hace algunas semanas pensé “cómo será vivir sin esta presión por conseguir resultados para no dejar de existir?” “cómo vivía antes o cómo funcionaba mi cabeza antes de vivir así?”.
una startup es una función de tiempo vs. resultado. es así porque una startup por definición se está quedando sin plata. en esos meses que logré conseguir levantando capital (que pueden ser 12/18/24) tengo solamente una cantidad de oportunidades. de semanas, de sprints, de releases que puedo hacer, de cuentas que puedo cerrar. cómo las quiero elegir? en qué features me quiero enfocar? cuáles van a hacer que tenga el resultado más grande en el marco de tiempo que tengo?
la escasez de tiempo hace que tome decisiones pensando en función de los resultados. hay algo agobiante en eso y también hay algo liberador. la escasez me da un marco en el que tomar decisiones. como no hay tiempo ilimitado no puedo probar todos los caminos ni todas las ideas. tal vez solo puedo probar 3 o 4. cuáles quiero elegir?
por otro lado pensar todo desde la escasez es tramposo. una startup debe ser algo inmenso. startup = growth dice Paul Graham. es importante recordar que lo que hagamos nos tiene que permitir estar a múltiplos de dónde estamos ahora.
el problema de pensar todo en función de los resultados es que nos recorta la exploración. será que ser un buen líder es entender cómo equilibrar los resultados y la exploración? la exploración es importante porque es la que nos permite crecer a múltiplos de donde estamos ahora. pero es importante combinar esa exploración con ciclos muy cortos de iteración.
al escribir esto recuerdo General Magic (una película que cuenta la historia del device que fue el antecesor del iphone). cuando la vi me pareció obvio que esas personas estaban más interesadas en hacer arte que en hacer producto (una de las entrevistadas cuenta que estuvieron varios meses diseñando las animaciones de los íconos que iba a tener el aparato). es difícil pensar en el iphone sin General Magic pero lograr ese equilibrio parece ser lo difícil. explorar y al mismo tiempo hacer producto. la escasez de tiempo es una muy buena herramienta para eso.
cosas que leí últimamente que hablan uso del tiempo:
- 100 blocks a day. https://waitbutwhy.com/2016/10/100-blocks-day.html
- Reality has a surprising amount of detail: http://johnsalvatier.org/blog/2017/reality-has-a-surprising-amount-of-detail
- Focus: https://boz.com/articles/focus
- How to get rich (pésimo nombre pero increíble nota): https://nav.al/rich/
- Speed matters: http://jsomers.net/blog/speed-matters
mi máximo aprendizaje vendiendo b2b en el último tiempo es que lo único que importa es entender si una cuenta necesita nuestra solución ahora, en el largo plazo o nunca. dos cosas sobre esto: durante mucho tiempo clasifiqué las cuentas en qualified y no qualified. creo que es importante subdividirlas en las qualified que necesitan este producto ahora y las que no. lo segundo es que para identificar esto tuve que mejorar las preguntas que hago e inconcientemente creo que mi proceso viene siendo tratar de llegar al no. quiero describir las cosas que hago que creo que funcionan.
se me ocurren algunas razones:
1) valor vs. esfuerzo. nuestro producto es difícil de presupuestar pero no es el caso de todos los productos b2b. porque es difícil de presupuestar una cuenta que nos deja USD200 de revenue nos toma el mismo trabajo que una que nos deja USD10,000. prefiero hacer ese proceso con una cuenta que tiene una urgencia ahora. nos da foco, nos da velocidad y nos permite cerrar más.
2) no pipeline BS. es fácil mentirse estando en sales y pensar que todas las cuentas que expresan interés o que tienen un problema van a ser clientes. una forma de evitar ese autobullshit es solo enfocarse en las cuentas que necesitan solucionar un problema ahora. yo no creo que exista en la venta b2b el ‘crear la necesidad’. creo que las cuentas tienen un pain o no lo tienen. si lo tienen lo que importa es entender budget, timeline y decision maker. si tenemos esas 3 (y el timeline es ya) tenemos más chances de cerrar esa cuenta.
3) crea buzz en el equipo. cerrar importa. no da igual no cerrar nada en un mes que cerrar 3 o 10 cuentas en un mes. no importa si las cuentas son grandes o chicas. traer clientes genera sensación de urgencia y no traer cuentas genera que el equipo esté cómodo y tranquilo. enfocarse en las cuentas que necesitan esto ahora importa porque trae clientes y traer clientes genera movimiento y urgencia en el equipo.
escribiendo de esto me doy cuenta de que hago esto para evitar mi auto-bullshit de que una cuenta va a cerrar cuando es posible que no. algunas de las cosas que hago para llegar al no:
1) mi primera pregunta es por qué estamos acá. esta pregunta apunta a que el otro te diga su pain o su necesidad. hay gente que tiene claridad de esto y gente que no. una buena respuesta puede ser “tengo X problema con el equipo y pienso que esto lo puede solucionar” o “tengo X métrica que me dio mal y necesito mejorarla”. por el contrario que no haya una respuesta concreta en este punto no quiere decir que no haya un pain. solo quiere decir que hay que escarbar un poco más para que aparezca.
2) lo único que me importa en la primera llamada es encontrar un pain. tienen una situación que resolver? una métrica que mejorar? un equipo pidiendo algo? una manager con ganas de solucionar esto? o están viniendo a ver qué onda? eso es lo único que importa. la mayor parte de la gente no pierde el tiempo en una llamada si no tiene un problema concreto pero muchas veces no te lo quieren decir. vamos a asumir que si tienen un problema lo quieren solucionar.
3) les doy toda la info en la primera llamada. mi objetivo es que me digan cosas como: este producto no me sirve, es muy caro, no solucionas X problema que yo tengo, esto no sirve para X grupo de gente. les doy toda la info en la primera llamada porque quiero llegar a esas frases lo antes posible. si tengo una demo o doy pricing en la call 2 o 3 tal vez me entero en la llamada 3 que esta empresa nunca podría haber pagado por esta solución. necesito saberlo cuanto antes para no perder tiempo en esta cuenta. si después de mostrarles todo quieren seguir hablando es un muy buen indicador.
4) busco que me digan que no quieren volver a hablar. si todo eso salió bien, hay un pain, les dije precios, les mostré el producto y les digo que hablemos de nuevo en 2 o 3 días para ver más detalles espero que me digan que no si no hay una necesidad real. si hay una necesidad y una urgencia ellos mismos me van a pedir más detalle y volver a hablar. que me digan que sí a otra reunión después de haber visto todo es buena señal.
5) busco si quieren saber precios y detalles de implementación. más allá del pricing general que le puedo dar en una primera conversación si la cuenta tiene algo real por resolver va a querer saber detalles de implementación. eso es porque comienzan a pensar en cómo se vería esto en su equipo. siempre después de una call trato de agendar una siguiente y un muy buen indicador de que la cuenta no tiene una urgencia es no querer agendar esa reunión. sobre todo en la venta en latam donde hablar de precios tiene más carga que en US proponerles una llamada para ver precios en detalle es ayudarlos a decirte que no. si te dicen que sí es un buen indicador.
6) como resumen general: busco que la cuenta me diga sí quiere avanzar en vez de yo empujarlos a avanzar. esta semana tuve una cuenta que me dio un verbal yes. en vez de enviarle automáticamente el contrato se lo pregunté: querés que te envíe el contrato? hay dos respuestas posibles: “esperá que hablo con X para definir X y te aviso” o “sí por favor”. creo que es un micro ejemplo de esto que estoy probando. incluso después de que me dijo que sí quiero saber si es algo para ahora o es para después. si es urgente la respuesta va a ser que sí. si está pensando en implementar esto en 3/6 meses me lo va a patear para más adelante (y si es así lo quiero saber cuanto antes).
algunos disclaimers de mi método: 1) nosotros tenemos muchos leads calificados y podemos permitirnos hacer este recorte. no todas las industrias son así. a veces los lead son pocos y calificados menos. 2) nuestro producto se puede vender rápido si los intereses están alineados. hay productos que necesitan un sales cycle de meses por el producto mismo. no es nuestro caso. 3) es muy importante equilibrar esto con muchas ganas de cerrar estas cuentas. creo que es fácil leer este playbook con los ojos érroneos y no cerrar nada o buscar excusas para justificar que una cuenta no avance. esto solo funciona porque yo todo lo que quiero es cerrar estas cuentas, no estoy enfocada en el no porque quiera trabajar menos o peor sino porque solo quiero priorizar las que van a cerrar urgente.
- no avanzar en nuestro pipeline oportunidades que no tienen un pain ahora. creo que las calls calificadas se pueden separar en dos: in pain now, not in pain. las IPN son las únicas que deberíamos pursue. las otras deberían ir a long-term (a falta de mejor categorización). muchas veces confundimos empresas que son target con empresas con una necesidad real. creo que es fundamental en la primera reunión encontrar indicadores de que la empresa necesita solucionar este problema ahora. en mi experiencia eso viene siendo preguntarles si quieren un presupuesto más detallado para tomar una decisión y que acuerden una segunda reunión. la empresa que no tiene una necesidad real va a decir que no y la que sí te lo pide ella misma.
- la co-creación con el champion es importante porque genera trust. creo que un descubrimiento para mí es que a veces podemos ‘apurar’ las cuentas sin querer. creo que queremos apurarlas para mejorar el deal velocity nuestro pero que va en contra de lo que la persona del otro lado querría. en mi experiencia se necesitan al menos 3 reuniones con interlocutores de latam para generar ese trust. se ve en que 1) acuerden tener otra reunión 2) en cada reunión sucesiva te comparten más info de su pain. el trust no se genera solo con reuniones sino con co-creación. la co-creación puede ser de la propuesta o de la presentación al decision maker.
- al venderle a un rol que no es el decision maker siempre hay un momento que es un black box. nuestro producto es para heads de people. los heads de people necesitan validar su presupuesto con finance o con la CEO. aunque acompañemos ese proceso desde el principio y hayamos construido trust con esta persona hay un momento que es un black box que es cuando le presentan al decision maker. hay cosas que podemos hacer antes de ese punto para darle soporte a la persona pero en última instancia queda de su lado. tengo todavía que aprender cómo ayudamos al champion más en esta instancia o cómo hacemos para que esto no sea un black box.
1) aprendí muchísimo sobre cómo vender este producto entrevistando candidatos/as. creo que aprendí de todos incluso de quiénes no eran buen fit. las preguntas que hacían, sus presentaciones, sus tácticas para agendar una siguiente call. también aprendí mucho por ver desde afuera como creo que no se debe vender un producto b2b. mi aprendizaje a alto nivel es que siempre aprendo muchísimo de ‘entrevistar’ aunque no sea específicamente para contratar roles. conversar con personas mejores que yo siempre me enseña cosas que puedo aplicar casi instantáneamente.
2) cuando las llamadas de venta se repiten y todos los clientes dicen exactamente lo mismo, tienen exactamente el mismo pain, quieren el mismo next step hay product-market fit. tuve la misma sensación cuando vendíamos b2c: después de la call número 10 todas las calls eran exactamente iguales. mismo pain, mismo perfil, misma urgencia. ver un proceso repetible me da la pauta de que es un producto con PMF (lo pienso al revés: qué brutal sería si todas las calls fueran diferentes, quisieran productos diferentes, o quisieran que el next step fuera otro).