crear una startup que sobreviva es tan difícil que creo que a veces elegimos ideas más por viabilidad que por gusto. como cualquier startup que tiene éxito toma 10 años estas son algunas ideas de problemas grandes para los siguientes 10.

- spaceships/rockets. creo que si esa no es la primera de la lista tengo las prioridades en desorden. seguramente no sea para mí pero qué divertido.

- personal robots. robots que te acompañen, que resuelvan cosas, pero más bien que sean una compañía. cubix robots for everyone: https://en.wikipedia.org/wiki/Cubix.

- ai something. las maneras de aplicar ai al b2c me parecen más aburridas que las b2b por alguna razón. la asistente personal con la voz de scarlett johanson no me interesa. sin embargo si pienso en problemas complejos, problemas más de ‘piping’, que se pueden resolver con ai me interesa mucho más. (pienso: problemas de integraciones, de interconexión, de sistemas hablándose entre sí).

- infraestructura startup para latam. este problema me divierte porque sé la complejidad de hacer una startup en latam. algunos supuestos: 1) comenzar una startup en US es mucho más fácil que en latam 2) para hacer una startup en latam hay que hacerlo en todo latam (no se puede hacer un único país excepto que ese país sea brasil) 3) latam tiene complejidades a nivel operativo que US no tiene cuando uno quiere emprender en la región (pagos entre países, entidades legales, regulaciones distintas). la startup ideal en este espacio ayudaría al procesamiento de pagos (stripe for latam) y al establecimiento legal. es el camino que están haciendo yuno, pomelo y otras. el ideal al que apunto es: una estructura para emprender que haga que sea igual de fácil emprender en latam que en US.

- ai for government. creo que el futuro de los gobiernos es un modelo entrenado con la información del país que nos informe de cuál es el siguiente next step que hay que hacer.

- something something transportation something something. patinetas que vuelan? volar con propulsores? autos voladores?

- smart furniture. aparatos electrónicos inteligentes.

- gpus. cómo podemos hacer para desarrollar gpus (o lo que le siga) con otros recursos naturales que no sean los actuales?

si solo vas a leer una cosa de esta nota que sea esta: algunas personas trabajan lento porque piensan que a todas las tareas de su to-do list le tienen que poner la misma dedicación. creo que trabajar inteligentemente es saber qué items de mi lista determinan el éxito de mi proyecto y cuáles no. Gracias. A continuación otras ideas sobre velocidad.

escribo esto porque muchas veces le digo a mi equipo que quiero que seamos más rápidos y me doy cuenta de que no se entiende por qué. estas son algunas de las cosas que creo que piensan cuando les pido que sean más rápidos: 1) esta persona no entiende lo difícil que es lo que estoy haciendo 2) no puedo hacerlo más rápido porque lo voy a hacer mal 3) si lo hago mal o imperfecto esto quiere decir que trabajo mal 4) la manera de trabajar bien es obsesionarme con la calidad de lo que hago 5) esta persona me está pidiendo que haga algo a medias 6) esta persona me está pidiendo que trabaje después de hora para tener esto antes. 

ninguna de estas cosas es cierta. quiero escribir sobre esto en parte porque quiero hacer el ejercicio de pensar qué es velocidad para mí y por qué me resulta tan natural algo que para muchos es contraintuitivo.

(creo que debería hablar de por qué la velocidad importa pero en vez de hacer eso voy a linkear a cuando hablé de por qué creo que importa hacer cosas imperfectas. creo que es otra forma de hablar de lo mismo).

por qué creo que las personas a veces son lentas

1) no saben que la velocidad importa. creo que la primera razón es que nadie antes les ha dicho que la velocidad importa. seguramente porque vienen de entornos laborales con otro pace o porque en Latam no hay sentido de la urgencia en el mundo startup. esta semana le dije a alguien de mi equipo que tenía que resolver algo más rápido y me dijo que le preocupaba que le pidiera eso, que le hacía preguntarse si nos estábamos quedando sin plata o a la empresa le estaba yendo mal. esa interpretación es super razonable porque en el ecosistema startup de Latam no hay sentido de la urgencia. no hay otros haciendo lo mismo que vos (o haciendo productos mejores, o sacando features más rápido). no miramos lo que los demás hacen. no está muy bien visto competir (al menos en Argentina). por fuera de eso por definición una startup siempre se está quedando sin tiempo. esa debería ser razón suficiente para valorarlo.

2) piensan que todas las tareas de su to-do list tienen la misma importancia. voy a dar un ejemplo: estoy tratando de cerrar una venta. cerrar una venta implica varios pasos: hacer una presentación, elaborar un ROI, tener y preparar reuniones, armar presupuestos. si pienso que todos los items de esta lista tienen la misma importancia le voy a dedicar la misma energía a todos. pero el diseño de la presentación, por ejemplo, no tiene la misma importancia que hacer un ROI. un problema que veo es que algunas personas piensan que a todas las cosas que hacen le tienen que poner la misma dedicación. estoy absolutamente a favor del perfeccionismo pero solo deberíamos intentar ser perfectas en las cosas que importan. creo que trabajar inteligentemente es saber qué items de mi lista determinan el éxito de mi proyecto y cuáles no. es importante no dedicarle la misma atención a todo y es importante desarrollar la intuición de qué es lo que importa y qué no.

3) trabajan con herramientas o sistemas ineficientes. creo que es más fácil entender esto cuando hablamos de ingeniería pero creo que lo mismo aplica a procesos mal diseñados. cuando lo que tengo que hacer me toma el doble de tiempo porque hacerlo me genera muchísima carga cognitiva voy a ser lenta. en el código es fácil de identificar cuándo pasa esto: es en los momentos en que una programadora tiene que hacer una tarea y la mitad del tiempo se lo pasa pensando en si hacer lo que tiene que hacer o si reescribirlo todo. yo creo que en estos casos puede ser mejor invertir el tiempo de corregir el sistema de raíz en pos de ganar velocidad en el futuro.

4) no recortan, hacen todo lo que está en su to-do list. hace un montón de años me enseñaron el sistema que se llama get shit done que dice que frente a una tarea lo primero que hay que preguntarse es si la puedo delegar (si se puede, lo hago); si no puedo tengo que preguntarme si la puedo hacer en menos de 5 min (si se puede, lo hago en el momento); si no se puede lo tengo que calendarizar y si no lo puedo calendarizar lo tengo que borrar de mi lista porque eso quiere decir que nunca lo voy a hacer. una parte de ser rápidas es borrar items de nuestra lista. es importante recortar sin asco y saber que si algo importa va a volver.

5) no se ordenan en unidades pequeñas de trabajo. una manera muy normal de ser lentas es perder el tiempo. perder el tiempo a veces es trabajar en cosas que no son importantes ahora. a veces frente a un proyecto grande tenemos la tendencia a comenzar por la parte que nos parece más difícil. es muy importante hacer lo contrario: hay que empezar por la unidad más chiquita y la más fácil y rápida de completar. esto importa porque una tarea terminada nos da la energía para tomar otra tarea. en vez de comenzar por lo grande y difícil hay que comenzar por lo pequeño y lo fácil (el low-hanging fruit). la otra cosa que importa es que el trabajo que tenemos que hacer esté ordenado en bullets chiquitos y asequibles. y es importante ordenarlos de menor mayor (en orden de tiempo que me va a tomar completarlos) y comenzar de a uno.

6) piensan que algo bien hecho es algo que tomó mucho tiempo. yo creo que algo que tomó mucho tiempo, por el contrario, es algo que estamos haciendo bajo supuestos que pueden ser incorrectos. el problema de tardar mucho en completar algo en que estamos a ciegas. recién vamos a recibir feedback cuando tengamos el producto final. y si el producto final nos tomó 3 meses eso puede querer decir que estuvimos 3 meses trabajando bajo supuestos incorrectos. otra forma de pensar en la rapidez es pensar que lo que estamos haciendo es compartir nuestro proceso. hay algo de ego en querer compartir el producto terminado (no queremos que nos critiquen por algo incompleto). es importante que trabajemos en no sentir eso porque nos hace perder el tiempo (además de que es un fantasma: nada le gusta más al otro que la vulnerabilidad de que les muestres un producto incompleto para que te ayuden a construirlo).

7) resuelven problemas que piensan que van a tener en el futuro en vez de problemas que tienen ahora. creo que acá la pregunta importante es cuántos usuarios realmente vamos a tener de acá a los próximos 6 meses. normalmente los roles del lado del negocio tienen alguna estimación de esto. si es un negocio b2b sabemos que la meta de crecimiento mensual es 20% y que eso quiere decir X número de users al mes. hay que armar un sistema para ese número de users. de nuevo creo que es más fácil pensarlo en programación. para mí un indicador de que unx dev que sufre de este problema es que hable de 'escalar' o los problemas de la escala y que justifique su estrategia con la escala. cosas que se justifican con la 'escala': armar sistemas complejos de colas, notificaciones, medición, etc. obviamente la línea es muy fina entre cuándo estas cosas importan y cuándo no. por eso es importante entender el uso real que van a tener las cosas que estoy desarrollando.

habiendo listado todas las cosas que creo que hacen que algunas personas sean lentas podría listar las cosas que creo que nos hacen ser más rápidas. en pos de cumplir con mi propio consejo no lo voy a hacer porque sé que esta nota así como está suma mucho más ahora que yo dedicándole otros 3 días de trabajo. espero que sirva como está y espero poder seguir aprendiendo de este tema para volver a escribir en el futuro.

Hubspot es una herramienta espantosa. En Atlas la usan todos los equipos y ahora que formo parte informalmente de nuestro equipo de ventas yo la uso en el día a día.

Hubspot nunca adivina lo que quiero hacer a continuación. Estas son algunas de las cosas que me frustran de la experiencia:

- Hay un Cmd + K que sirve para hacer búsquedas en toda la app pero funciona lento. Le toma fácilmente 3 segundos en cargar después de escribir una búsqueda lo que le sacá el propósito al shortcut (es más rápido clickear la opción en la barra de la izquierda). En los resultados de la búsqueda nunca me sugiere primero lo que estoy buscando. El orden de los resultados de búsqueda es Contacts, Companies, Deals. Si busco el nombre de una empresa (porque claramente quiero ir al perfil de la empresa) primero tengo que ver una lista de contactos que pertecen a esa empresa porque ese es el orden en que muestra los resultados. Si busco una persona por email me devuelve un listado con todas las personas que se llaman parecido. Si la persona no existe es evidente que la quiero crear pero crear es otro flow completamente separado.

- Tener que guardar cambios es muy frustrante. En las demás UIs, desarrolladas en los últimos años, los cambios se guardan a medida que voy editando. Tener que presionar 'guardar' es frustrante sobre todo porque es difícil entender el scope de qué estoy guardando. El botón de guardar ¿aplica a toda la pantalla que tengo activa o solo al input que acabo de tocar? ¿puedo seguir editando cosas y lo va a almacenar todo o solo lo que edité primero? Demás está decir que si accidentalmente actualizo la página pierdo mis cambios.

- Configurar cómo se ve la plataforma es muy contraintuitivo. Para configurar cómo se ve la plataforma hay que ir a Settings y casi todo hay que editarlo dentro de Objects. No hay un orden lógico ni en settings ni en Objects. Normalmente lo que tengo que hacer es leer el listado completo de opciones que me da la pantalla para ver si esconde lo que busco. Normalmente no lo encuentro y tengo que googlear cómo hacer lo que quiero hacer.

- La pantalla de workflows es muy contraintuitiva. Para hacer una automatización hay que partir de un objeto lo que me parece rarísimo (normalmente el patrón es comenzar desde un evento). No voy a entrar en detalle en esta parte porque podría escribir un ensayo entero sobre lo mal que funciona la parte de workflows.

Pero hubspot es una herramienta increíble. Y es increíble por razones que escapan a los problemas que estoy describiendo. Si alguien estuviera desarrollando otro CRM y me pidiera que lo probáramos en el equipo no podría y la razón es clara: Hubspot está integrado a todo nuestro flow de trabajo (al de 3 equipos: marketing, sales y CX). No podemos ‘simplemente probar otro CRM’. Tomaría un tiempo de implementación altísimo. Esto me llevó a preguntarme cómo haría alguien que quiere disrumpir este espacio para ganar contra Hubspot. Estás son mis hipótesis.

Las cosas que Hubspot hace bien

Hay que partir por entender qué la hace una buena herramienta y yo creo que son estas características:

1) Integración con el resto del stack (se integra con herramientas de performance tipo SEM/Fb ads, con herramientas de outbound tipo Apollo, con Gmail y otros proveedores de emails, con Stripe y otras).

2) Centraliza la información de 3 áreas al menos: cx, mkt y sales. Es el single source of truth de estas 3 áreas. Van a esta plataforma a consultar métricas y a hacer seguimiento de su trabajo.

3) Integra como ninguna otra el trabajo de mkt y sales: esto es muy importante porque las herramientas que son solo buenos CRMs no hacen esto y complica el sales cycle. Cuando podemos integrar los leads de mkt y sales y tenerlos en el mismo lugar es más fácil hacer campañas de remarketing o entender el ciclo de vida completo de una cuenta. Lo mismo pasa cuando esas mismas cuentas pasan a CX para expansión. Toda la información está concentrada en el mismo lugar.

4) Es gratis. esto es complejo para una startup. Competir con un producto que es gratuito es muy challenging porque la solución tiene que ser efectivamente mejor para que alguien la elija vs. la versión gratis y consolidada.

Por dónde comenzar para poder competir

Quiero listar cuáles son los challenges de querer hacer una herramienta que compita con Hubspot:

1) Para una organización tiene un costo altísimo moverse a otra. Esto se podría solucionar vendiendole solo a startups al principio y supongo que ese sería un primer approach naive que no creo que sea una buena idea (por qué: las startups se gradúan de vos; necesitan más cosas; ‘startup’ puede significar 10 mil cosas distintas).

2) Para que funcione tiene que desde el día cero integrarse a tu stack actual. Esto es costoso porque hacer integraciones es complejo y toma tiempo. Lo más complejo es entender con qué integraciones comenzar. Acá tengo una idea muy clara. Creo que un mal approach sería ‘lo que los usuarios pidan’ o copiar las más populares de Hubspot de hoy.

Cómo ganarle a hubspot

Primer statement: va a nacer una herramienta que repiense este espacio y desarrolle una herramienta mejor. Es el ciclo natural de cualquier industria y Hubspot, comparada a herramientas que nacieron en los últimos 5 años, tiene shortcomings que son evidentes para el usuario de hoy. Va a nacer otra que va a resolver este problema 10x mejor con tecnología de hoy y le va a ganar marketshare del mismo modo que hicieron ellos con Salesforce.

La pregunta difícil es cómo debería comenzar esta herramienta y acá el problema a resolver para mí es claro: cómo desarrollar una herramienta que sea una mejor versión de Hubspot en el menor tiempo posible generando revenue desde el día cero. El challenge está en la escasez de tiempo: cómo hacer para generar revenue con este competidor en el menor tiempo posible. Parafraseo: qué características tiene una herramienta que se pueda desarrollar en 4 meses o menos que me permita sacarle clientes pagos a Hubspot desde el día 0.

Mi solución

1) Seleccionar un único segmento. Hubspot debe tener muchos tipos de clientes. Por ejemplo imagino que diferentes industrias deben hacer un distinto uso de las herramientas que tiene Hubspot (que son miles). Por ejemplo un ecommerce debe hacer un uso distinto a un b2b saas. Un b2b saas debe hacer un uso distinto a un b2b con usage-based pricing.

Hay que seleccionar solo uno de esos segmentos y entender cuáles son los features que son prioritarios para ese grupo y esa industria. Voy a elegir una porque siempre con ejemplos es más fácil: un equipo de sales de b2b saas usa solo algunas cosas:

- Integrations: linkedin ads sí. instagram ads no. gmail sí. outlook sí. google calendar sí. zoho no. intercom no. stripe sí.

- Features: sales pipeline sí, automations sí (pero solo una: hay que entender cuál pero si tengo que adivinar diría que la número uno es actualizar un deal cuando suceden diferentes eventos).

Hay algo muy importante en el paso de elegir uno y solo un segmento: hay que ser inflexibles. No vamos a integrarnos con intercom. No vamos a integrarnos con zoho. No vamos a sumar automatizaciones que necesite marketing.

El foco tiene ser brutal y tiene ser demagógico. Solamente vamos a hacer eso. Cuándo podemos dejar de hacer eso? Cuando tengamos una solución 10x mejor que la que tiene Hubspot para ese segmento. Ese es mi paso 2.

2) La segunda cosa que tenemos que hacer para ganar es tener una solución 10x mejor que la que tiene Hubspot pero únicamente para ese segmento. Qué es ser 10x mejor? la herramienta tiene que adivinar lo que necesito y lo que voy a hacer a continuación. La única forma de llegar a esta calidad de producto es nosotros ser los primeros usuarios de esta plataforma (nosotros tenemos que ser sales en b2b saas para poder ser usuarios) y es muy importante que nos obsesionemos con resolver el único problema que tiene este usuario. Qué problema es? cerrar deals. Cómo puedo hacer para que la experiencia de cerrar deals sea 10x mejor que la que tiene Hubspot? Tengo que obsesionarme con ese flow y únicamente con ese flow. Cómo sé que mi solución es 10x mejor? Los usuarios te lo van a decir.

3) Este juego solo se gana con velocidad y con revenue: nada de esto importa si desarrollo algo a puertas cerradas durante 4 años solo para descubrir que no funciona. Las variables por las que hay que optimizar acá son velocidad y revenue y las dos son las únicas que importan. Qué características tiene un producto por el que la gente pagaría después de 4 meses de desarrollo es la única pregunta que tengo que buscar responder. No se pueden flexibilizar ninguna de las dos variables y voy a explicar por qué.

Por qué no puedo alargar mi release en el tiempo: primero por una cuestión de supervivencia (todas las startups se están quedando sin plata siempre) pero además porque un ciclo corto de desarrollo nos garantiza tener feedback del usuario más rápido que es la única forma de tener un buen producto. Ya hablé sobre por qué importa lanzar cosas incompletas pero el resumen es ese: hay que validar con usuarios y hay que construir con su feedback.

Por qué no puedo ofrecer un producto gratis: porque en este momento lo que estamos haciendo es un experimento. El experimento es si hay un business en esta idea. Ese es el único experimento que estamos haciendo. No estamos probando que al usuario le guste nuestra app, ni que la quiera usar, ni que le resuelva un problema. Lo único que estamos intentando probar es que el problema que resolvemos es lo suficientemente hair-on-fire y la solución antes de nosotros es tan peor que la los usuarios están dispuestos a pagar por nuestra solución. Un mvp es un mvp del negocio, no de la tecnología. Lo que queremos probar acá es willingness to pay y nada más que eso.

Entonces volviendo: las dos variables que no podemos tocar en este juego son velocidad y revenue. A mí eso me da muchísima paz porque me marca un terreno de juego. Esto significa que todas las demás variables que no sean estas dos se pueden editar. por ejemplo: puedo en vez de hacer una app hacer un grupo de whatsapp con mis usuarios y que ellos me cuenten cómo van sus deals y actualizarlo yo a mano en un excel? sí. (acá hay un challenge más que es que esta es una industria establecida y que este producto no es category defining por lo que soluciones berretas como esta no siempre van a funcionar. El usuario espera producto porque ya conoce la categoría).

Cómo seguir

Pensaría que una vez que tengo el producto que describí antes lo que queda hacer es hacer lo mismo pero para un segundo grupo de usuarios. En mi caso yo seguiría por marketing porque me parece que la unión del trabajo de ambas áreas es lo que lo hace tan importante. Pero no podemos movernos de la industria. No importa cuántos mensajes reciba por Intercom de que tenemos que agregar una integración con Shopify. Solamente resolvemos un problema para b2b saas (ahora para sales y para marketing).

Esto fue un thought experiment para mí. Lo escribo porque me divirtió pensarlo y me hizo pensar en los puntos de cercanía y no cercanía con el problema sobre el que yo trabajo hoy (que no es este). Lo comparto por si a alguien más le sirve y porque todo lo que importa es deployar incluso si hablamos de deployar texto.

estuve pensando en la importancia de las ideas incompletas. en mi trabajo diseñando y desarrollando productos es importante construir cosas y lanzarlas a medias. las ideas detrás de por qué lo hacemos son dos: 1) lo único que importa es la velocidad y 2) es un safety net para no trabajar durante un tiempo largo en algo que nadie quiere. 

me importa sobre todo la segunda: lanzar un primer modelo y construirlo en base a feedback es mejor que lanzar un producto terminado.

pensemos en las ventajas de los productos a medias para entender por qué: 

1) los productos incompletos nos dan ganas de quejarnos: cualquiera (desde mi mamá hasta un cliente de nuestro ICP) va a tener ideas sobre cómo mejorar algo si ve un producto feo, incompleto. te lo va a decir y de manera muy pasional. lo feo nos incomoda. queremos corregir lo feo. (en un mundo en el que obtener feedback honesto es difícil esto me parece invaluable).

2) los productos incompletos son un ego-check. pensemos en cómo se construye un producto de principio a fin. pienso en el ejemplo de Humane. su foundational story es: mucho capital y trabajo a puertas cerradas durante 2-3 años. el problema del trabajo a puertas cerradas es que no tiene feedback loops. si los creadores son personas sin autocrítica es posible que pongan en el mercado un producto que no le sirve a nadie porque en sus feedback loops internos nadie les dijo “este producto es una mierda y no puede performar acciones básicas”.  si la estrategia de Humane hubiera sido la de Rabbit (mismo producto pero hacker mind-set: “sabemos que esto es una mierda, esto es un beta, esto está roto”) se hubieran beneficiado de ese feedback loop. creo que el peor enemigo de un buen producto es la opinión de sus founders.

lo incompleto es incómodo. esa incomodidad viene de varios lugares. por mencionar uno: de un lugar de ego (qué van a decir de que este es el producto que hice?). esa incomodidad nos da ganas de crear. hay algo intuitivo que le pasa a un tipo de persona cuando ve algo feo que son las ganas de corregirlo. en esa corrección aparece la creación y en esa creación se genera movimiento.

a veces oigo personas en el mundo startup disconformes con lo incompleto. no lo entiendo porque yo creo que una startup es una idea incompleta. la persona ideal para una startup es alguien que disfruta de la incomodidad de lo incompleto.

con este mismo framework puedo pensar en otras cosas: cómo una gran corporación se siente como algo estático porque no hay espacio para la creación y no hay espacio para la creación porque hay un ilusión de completitud, de cosa resuelta.

cómo nosotras al ser personas incompletas estamos en movimiento, hacemos y creamos gracias a eso. sé que Lacan habla de esto. me gustaría poder explayarme más pero no conozco la idea en detalle. lo que creo que dice es que el deseo reside en lo que nos falta. es decir: deseamos (hacemos), nos movemos, nos dirigimos hacia, únicamente por lo que no tenemos, no por lo que sí. lo que guía el deseo no es lo que hicimos sino lo que todavía no.

intuitivamente tiene sentido: obvio que deseo lo que no tengo. es el comportamiento core del capitalismo. busco tener lo que no tengo. como no tengo, deseo. al mismo tiempo qué poderosa la idea de que convivimos con la falta. que la raíz de nuestro hacer no es lo que hicimos hasta ahora. no es la persona que formamos. es la parte sin respuesta. la que cuesta más trabajo señalar. y obvio que ese deseo no siempre se manifiesta con claridad (alguna vez se manifiesta con claridad?). nos encontramos entendiendo lo que deseamos haciendo y ese hacer nos hace quiénes somos. solo ahí develamos de nosotras mismas, buscando en la parte que nos falta, otro pedazo de lo que somos.

Escribí sobre cómo hicimos un producto con PMF en Atlas en un posteo anterior. Últimamente estuve pensando en otros modos de construir productos que tengan PMF y me he encontrado con otros ejemplos de cómo hacerlo y quería dejarlo anotado por acá.

• Vender antes de construir producto (the Atlas way). Un MVP que se pueda hacer en una tarde (un link a Stripe should be enough si el pain es lo suficientemente grande) y vender suscripciones. Empezar a desarrollar producto solo cuando hay suficiente volumen y no escala seguir resolviendo el problema a mano vs. hacerlo con tecnología. El problema de este approach es que no sirve para cualquier tipo de industria (pienso en productos que son complejos de desarrollar como biotech o hardware) y también con el tiempo pienso cada vez más que es un approach 'fuerza bruta' cuando uno no tiene ni idea de quiénes son sus clientes o dónde están. Creo que hay mejores maneras. Más sobre este modelo acá.

• Desarrollar producto dentro de otra empresa (the spin-off way). El principal problema de quienes hacemos producto es que muchas veces hacemos producto porque nos gusta aunque no haya nadie dispuesto a comprar. La ventaja de ser un producto adentro de una empresa más grande es que desarrollamos necesariamente para un cliente (aka la empresa dentro de la que estamos) y podemos tener la certeza de que el producto estamos haciendo es necesario y alguien pagaría por él. 

(Voy a contar un ejemplo de una idea que es así porque creo que puede servir a otros para pensar si una idea tiene PMF:).

En Atlas los equipos siempre necesitan más tecnología y algunas veces aparece una idea que pienso que podría ser una empresa en sí misma. Tengo una idea en la que pienso mucho últimamente de este tipo. Mis indicadores de que tendría PMF son que: 1) entiendo perfectamente el problema y sé for a fact que no existe una solución porque ya buscamos en las herramientas disponibles )(por lo que este producto sería un "Category-defining product") 2) sé que es necesario porque nuestro equipo lo necesita y entrevisté suficientes perfiles en ese rol que sé que esto siempre es un pain 3) creo que es una industria que se puede actualizar y una herramienta así lo haría (mejor UX/UI que lo disponible; otro appoach a las soluciones que ya hay) 4) conozco los primeros 20 clientes de esta empresa y sé que lo usarían (empezaría por nuestros clientes de hoy con quienes ya hice vínculo y que tengo confianza) 5) puede describir perfectamente el ICP de los primeros 100 clientes (creo que serían founders ingenieros que tienen este problema en empresas chicas de < 100 empleados, B2B, US based) 6) sé que es un producto sticky pq se integra con todo tu stack actual 7) sé que es para un equipo en empresas que tiene budget y al que sería fácil vender.

Creo que hay otro approach pero todavía no termino de sacarle la ficha: the Notion/Figma way. Desarrollar algo a puertas cerradas durante años y salir y tener un muy buen producto al que le va bien. Creo que el problema de este approach es que todos se piensan Ivan de Notion o Dylan de Figma y la verdad es que pocas personas hacen producto de esa calidad teniendo cero feedback de usuarios. La pregunta que me hago porque no lo sé es si efectivamente estas personas no tuvieron feedback o fueron lanzando pequeñas iteraciones. Con la info que tengo hoy pienso que la única manera de hacer esto y que salga bien es conocer suficiente sobre una industria como para saber que ese producto es necesario. Creo que si uno es un experto en un problema puede desarrollar algo solo con base en lo que sabe de ese problema y la solución va a estar on point. Tal vez la pregunta es si las personas que desarrollan productos con este approach son expertos absolutos en ese problema. Si me guío con mi experiencia con Palabra (mi startup sin PMF) la rta es no. Yo no era experta en ese problema. Necesitaba feedback para poder desarrollar un producto mejor.

• Ser un experto absoluto en un problema y desarrollar algo a puertas cerradas (the Notion way). Como dije antes creo que este approach solo funciona si uno es un experto en un problema y además es increíble ejecutando. No me animo a poner las manos en el fuego por este approach porque lo vi salir mal muchas más veces de las que lo vi salir bien (pienso en Humane y el producto que lanzaron hace poco). Creo que tengo que seguir pensando en esta opción pero si fuese unx founder sin experiencia sin duda iría por alguna de las dos primeras.

TL;DR: buscamos dos cosas: excelencia técnica y agency. En las entrevistas empujamos el conocimiento de la persona para entender hasta dónde llega. Contratamos gente mejor que nosotras.

Escribo esto porque creo que en esta ronda de contrataciones yo mejoré en mi habilidad de encontrar buen talento y quiero contar lo que hice. Me gustaría que esto fuera sobre 2 cosas: 1) cómo pensamos las contrataciones en Atlas y 2) cómo hacemos para encontrar el mejor talento.

Cómo contratamos

La gente que sumemos en este momento (<30) va a crear la cultura de Atlas para los próximos años. Buenas contrataciones nos hacen ahorrar tiempo porque son personas con autonomía y nos ayudan a crecer. Además buenas contrataciones es igual a trabajar con gente brillante que nos empuja para adelante y nos hace ser mejores a nosotras lo que es verdaderamente un lujo. Por estas cosas es importante que aprendamos a contratar bien.

Cómo es unx candidatx ideal para Atlas:

• Tiene autonomía, ownership, agency. Hace propuestas, pide lo que necesita. Propone cambios.
• Tiene expertiz técnica. 1% mejor de todas las personas que entrevistemos.
• Es mejor que nosotras. Esto quiere decir: con más años de experiencia; que hayan alcanzado milestones más complejos que los nuestros en su carrera en ese puesto; que nos de un poco de nervios que entre a trabajar al equipo porque sabe claramente más que nosotras.

Cómo encontramos el mejor talento

Aunque estemos de acuerdo en que queremos personas con autonomía y ownership es difícil identificar cuando las personas van a ser así. Voy a contar mi método para identificar estas personas (high agency) en mi último proceso.

Algunos lineamientos generales:

• Llevamos un proceso consistente de entrevistas. Idealmente mantener un excel con las preguntas que le hacemos a los candidatos y guardar las respuestas de cada uno para poder ser objetivas y comparar.
• Buscamos siempre 2 cosas: excelencia técnica y agency. La excelencia técnica la medimos con su experiencia habiendo liderado proyectos complejos. La agency la medimos preguntando por proyectos que hayan propuesto en sus trabajos actuales. 
• Empujamos en las preguntas que hacemos para saber hasta dónde llega el candidato. No nos quedamos con la primera respuesta que nos dan.

Qué es excelencia técnica

• Tiene que dominar su área de expertís.
• Tener ejemplos de proyectos complejos que haya desarrollado.
• Normalmente tener entre 5 y 8 años de experiencia en el área.
• Ser el 1% de los mejores candidatos que entrevistamos.

Cómo identificar excelencia técnica

- La forma de idenficarlo es preguntando sobre una experiencia en un trabajo anterior. A mí me gusta la pregunta de _cuál es el desafío técnico más complejo que tuvieron que solucionar_ (para roles no dev la pregunta puede ser simplemente lo más complejo). Esta pregunta para mí es una excusa para indagar en profundidad sobre ese proyecto.

Qué observo con la respuesta a esta pregunta:

- Que pueda hablar en gran detalle del proceso, las tareas, las herramientas, los challenges de lo que tuvo que hacer. _Un red flag_: que no entre en detalle, no hable de herramientas, sea muy generalista.

- Que pueda comunicar lo que hizo. Es importante que sepa contar de forma clara y ordenada lo que hizo y su rol. Si no lo puede hacer es una persona que en el día a día va a comunicar igual de poco claramente su trabajo. _Red flags_: hablar de varios challenges a la vez y no elegir ninguno en detalle; no ser claro/a en las explicaciones; que no quede claro qué tuvo que hacer.

- Su participación. Buscamos personas que hayan liderado o trabajado de cerca en el proyecto que está contando. No nos sirve alguien que trabajó en una porción chica del proyecto o solo recibió indicaciones de qué tenía que hacer. _Red flags_: que no pueda hablar en detalle del proyecto normalmente significa que no tomó decisiones en el proyecto. Tiene que ser capaz de responder por qué se tomaron las decisiones que se tomaron.

- Que sea un efectivamente un proyecto desafiante. Para los devs ejemplos de proyectos no desafiantes: consumir algo de una API; configurar un servicio en AWS; miraría con atención proyectos blockchain y cripto que muchas veces ocultan simpleza en el fondo con lenguaje complejo. Para roles de paid marketing ejemplos de ejemplos no complejos: productos que se vendan solos (ej: ECommerce); proyectos con presupuesto infinito; proyectos con objetivos como generar tráfico; solo haber hecho campañas en lugares cómo Argentina donde es mucho menos competitivo.

- Cómo se llevan con las repreguntas: mi ejercicio normalmente es hacer esta pregunta, escuchar la respuesta y parafrasear lo que me dijeron para ver si entendí el proyecto bien. Acá lo que hago es hacer preguntas de por qué muchas veces para tratar de entender todos los puntos anteriores y también hasta dónde llega el límite de lo que la persona sabe. Normalmente quienes no conocen tanto de lo suyo tienen problemas con estas repreguntas y puede ser normal que se pongan a la defensiva. Es importante ver esto porque es cómo sería esta persona en un contexto de construcción o desacuerdo en el día a día en el trabajo.

Qué es agency

• Hacerse responsable del área que le compete.
• Estas personas proponen, hacen cambios sin preguntar, conocen a fondo el contexto de lo que están haciendo porque les da información.
• Tienen opiniones; dicen lo que necesitan.
• Tienen ideas sobre lo que quieren que suceda y normalmente lo ejecutan sin preguntar.
• Son action-oriented. No se quejan.
• Organizan bien su tiempo. Arman su propio plan para lo que necesitan.

Cómo identificar que alguien tenga agency

- A mí me gusta pregunta por un proyecto que hayan propuesto en su trabajo actual (aunque no se haya llevado a cabo). La razón por la que pregunto esto es porque la gente que propone SIEMPRE propone. Es independiente del contexto, el trabajo, el rol, el área. Si no tiene ejemplos para contar es un no.

Qué observo con la respuesta a esta pregunta:

- Que sea un proyecto con impacto en el negocio y no sea “tooling”. Ejemplo de malas propuestas: para sales haber sugerido usar un CRM. Para devs: haber sugerido un refactor o librería. Para marketing: haber sugerido una herramienta, CRM, migración, etc. Qué es una buena respuesta: un proyecto que generó revenue o bajó costos; una idea de producto o negocio.

- Que pueda hablar de si funcionó o no y que para hacerlo hable de métricas. Si no habla de métricas significa que se guía por intuiciones y esto puede ser un problema.

- La creatividad: que sea algo que me interese, que me emocione escuchar, que piense WAW cómo no se me ocurrió eso.

atlas es el resultado de una startup que no funcionó (Palabra). Palabra surgió desde las ganas de desarrollar un producto y sin pensar quiénes eran los clientes o si existía una oportunidad de negocio detrás. creo que el año de trabajar en Palabra e intentar hacer el camino inverso (intentar vender algo que ya estaba desarrollado con un equipo a cuestas) hizo que Atlas solo naciera hasta haber tenido clientes.

el primer producto de Atlas fue una herramienta para solucionar la contabilidad de personas que trabajan desde Latam para Estados Unidos. nos pusimos de objetivo no desarrollar nada hasta tener la validación de que existía un interés por comprar una solución de este tipo. mi prototipo fue tener un link de Stripe por una suscripción mensual de USD25 y mi forma de validarlo fue agendar reuniones con gente que conocía (la mayoría de Twitter) e intentar vendérselo. no había app, no había scripts ni ningún tipo de desarrollo. literalmente todo lo que había era un link de cobro y mis llamadas agendadas. en esas llamadas yo les explicaba a estos potenciales clientes qué problema les solucionaríamos (altas y presentaciones fiscales, soporte mensual, facturación, etc) y mi objetivo era que compraran. en el segundo día de intentar venderlo tuvimos dos compras en la llamada misma (los esperaba a que buscaran su tarjeta de crédito) y vendimos 40 suscripciones al cabo del primer mes. eso nos sirvió para entender qué había una necesidad y solo ahí decidimos que Atlas (que al principio tenía otro nombre) empezara a existir. 

no desarrollar producto hasta no tener clientes está en ADN de lo que hacemos y hoy, 2 años más tarde, me hago algunas preguntas en relación a esto:

- cómo conservar esta práctica teniendo ya un equipo establecido.

- al probar ideas nuevas sin producto introducimos mucho trabajo manual. me pregunto cuál es el momento justo para escalarlo y abandonar las tareas manuales.

- qué significa que haya una validación. ej: si hay un cambio en el ICP ¿hay que volver a validar como si estuviéramos en cero?

una pregunta que me hago aledaña pero no estrictamente relacionada es cuál es el sweet spot entre desarrollar producto nuevo (es decir: pensar ideas que pueden servirle a un cliente out of thin air) y solo desarrollar lo que un cliente necesita/pide. habiéndolo escrito pienso que seguramente la respuesta sea el proceso descrito arriba: no se desarrolla producto hasta no tener una validación y la única forma de tener una validación es con un cliente comprando.

las etapas del proceso

me parece importante identificar cuáles son las etapas que tiene este proceso. voy a hacer un primer borrador:

1. idea: pensamos qué queremos desarrollar y para quién. el desarrollo tiene que ser un producto único y chico y tiene que tener un ICP definido.

ejemplo: los empleados de las empresas quisieran poder disponer de su salario antes de la fecha de cobro. el cliente ideal es una persona que trabaja en una empresa por un sueldo menor a $X y que tiene deudas o gasta más de lo que gana.

2. definir un prototipo: el prototipo tiene que cumplir con algunas condiciones:

- rápido: desarrollarlo no nos toma más de una tarde. hay que recordar que no estamos validando una app sino que un problema exista y que nuestro usuario ideal está dispuesto a pagar por solucionarlo. hay un supuesto detrás de esto que es que si este problema es verdaderamente un pain para el usuario y no existe ninguna otra solución en el mercado el usuario va a estar dispuesto a usar un producto defectuoso e incompleto (esto siempre termina siendo cierto si hay un *pain real* y no hay competencia, por eso tomarse el tiempo de desarrollar una app para validar que existe un problema es una pérdida de tiempo).

- no-code: el prototipo nunca es una app. normalmente son cosas como un form de Google Forms, una landing page hecha en Carddd, una conversación de whatsapp. Obligatoriamente tiene que ser algo que se pueda crear en un mismo día.

- convierte: el último paso del prototipo es que la persona compre. un prototipo que solo valida un interés (por ejemplo: que un usuario nos agende una llamada o nos deje su dirección de email) no valida que exista un mercado para nuestra solución. la única forma de validar una idea es con $$.

ejemplo de prototipo: para validar que los empleados quieren tener su sueldo on-demand compramos una línea de whatsapp y creamos una conversación con cada empleado y le pedimos que nos solicite un adelanto de su sueldo cuando lo necesite. Por cada operación le cobramos $X. Validamos cuántas conversaciones y compras tenemos a lo largo de una/dos semanas.

3. validar: buscamos clientes potenciales y les presentamos nuestro prototipo.

ejemplo: en el caso de la app de sueldo on-demand vemos cuántas conversiones tenemos a lo largo de X tiempo (nunca más de un par de semanas). hay una variable cualitativa que es difícil de recoger e informal: la variable de qué tanto pull sentimos del mercado, qué tanto la gente nos comunica que esto le cambia la vida, cuánto nos recomiendan en esas primeras semanas a conocidos. Es difícil de medir pero es muchas veces lo que determina (en conjunto con haber tenido muchas operaciones exitosas en lo que dura el experimento) que el prototipo sea un éxito.

4. escalar: con la solución validada y solo cuando no demos a basto en nuestra forma de ofrecer el prototipo podemos empezar a desarrollar una solución que nos permita escalar. este paso es que el que más me cuesta y creo que normalmente paso mucho tiempo en el paso 3. el riesgo de mantenerse mucho tiempo en el paso 3 y sobre todo con un equipo de trabajo es que la gente se habitúa a que las cosas se hacen de ese modo y pierden de vista que siempre estuvimos probando un prototipo y que el trabajo manual no es la solución final. poder determinar en qué momento hay que empezar a escalar una solución es algo que todavía me escapa. mi primera intuición es que debería ser automáticamente después de haber tenido un número X de validaciones (no puede ser después de la primera porque la primera puede ser un outlier); otro indicador puede ser si el equipo que ejecuta el prototipo manualmente está al borde del burn-out. eso es un indicador de que nuestro prototipo se extendió demasiado tiempo. otra forma que creo válida para saber cuándo escalar es ponerle una fecha de fin al prototipo. la fecha es siempre arbitraria y creo que no importa. lo importante es que una vez que el prototipo se valida hay que comenzar una solución (tal vez la parte difícil es identificar cuándo algo está validado?).

diferencia entre validación y product-market fit

últimamente pienso cada vez pienso en la irrelevancia del concepto de product-market fit. mi conclusión es que todos los productos tienen un mercado dispuesto a comprar pero que normalmente los problemas son otros: no saber cuál es ese mercado; saber cuál es el mercado pero no tener acceso a él; que el mercado sea demasiado chico; que existan demasiadas soluciones iguales para ese mismo mercado y que la nuestra por falta de positioning no pueda competir, etc.

creo que usamos la idea de PMF para hablar de soluciones con clientes pagos, que aman el producto, lo recomiendan, no churnean, etc. lo escribo y pienso: esta idea es válida y me gusta que exista pero al mismo tiempo tiene un componente mágico que me gustaría que no tuviera; que la vuelve poco concreta.

creo que la idea de validar un producto en un mercado es más concreta y es más binaria: un producto tiene un comprador determinado o no lo tiene y un comprador está dispuesto a usar una solución incompleta solo cuando realmente tiene un problema que no tiene solución mejor. lo bueno de esto es que si esta validación se da esto implica que tenemos un producto para quien encontramos un cliente dispuesto a pagar y que además es monopólico que creo que es lo mejor de ambos mundos.

algo a notar de esto es que nuestro proceso de validación no valida que exista “product-market” fit, sino más bien “product-customer” fit porque nuestra validación solo nos indica que este producto es necesario para un cliente determinado, que responde a un mensaje determinado y un pricing determinados. si cualquiera de estas variables se toca el proceso comienza de nuevo.

por esta razón un producto que funcionaba muy bien para un ICP puede no funcionar por completo para otro ICP distinto. eso no implica que el producto no tenga PMF, solo quiere decir que tal vez no tiene fit para ese customer en particular. un cambio de ICP al igual que un cambio de producto es volver a cero en el proceso de validación y tenemos que tomarnos el mismo trabajo que si estuviéramos empezando una startup nueva.

tengo la intuición por esto de que el proceso de PMF/validación nunca termina. cada nuevo feature, cada nuevo mercado al que nos queramos expandir, cada cambio de posicionamiento requiere el mismo trabajo que si estuviéramos empezando con una idea nueva porque nuestro “PMF” solo validaba un conjunto de supuestos distintos/anteriores.

- no desarrollamos producto si no tenemos un cliente dispuesto a pagar. Siempre tenemos que saber si un feature o un producto está en modo validación o en modo growth. Si está en modo validación no hacemos cosas de modo growth (como contratar, invertir en ads, setear procesos muy rígidos).

- no escalamos experimentos, solo escalamos procesos validados. Eso significa no invertir plata, desarrollar producto, no contratar, no comprar cosas (software), no invertir en ads (a gran escala, sí para validar) hasta que un proceso esté validado.

- tomamos decisiones rápido. si son decisiones que no tienen impacto en el largo plazo decidimos algo y avanzamos. Esas decisiones muchas veces van a ser decisiones por azar. No importa. Lo importante es hacer, validar con hechos y si la decisión fue mala tomar otra decisión igual de rápida para revertirla. No tenemos analysis paralysis.

- avanzamos rápido. buscamos constantemente en qué estamos siento lentas nosotras y como organización. Destrabamos cuellos de botella. Ejecutamos rápido. La perfección no importa. Importa la velocidad.

- para decisiones que tienen impacto en el largo plazo, en las personas, en toda la organización o impacto legal analizamos nuestros supuestos antes de avanzar: podemos validarlo con números? Podemos validarlo con clientes/willingness to buy? Ninguna cosa nos puede tomar más de una semana en tomar una decisión.

- somos owners de los detalles. Podemos hablar de los detalles de las áreas que lideramos y somos owners de todas las decisiones vinculadas al área. No tenemos un estilo de liderazgo hands-off. Estamos en el día a día y en el detalle. Nos gusta el extreme ownership. Para exigirlo al equipo necesitamos practicarlo nosotras primero.

- we hire slow and we fire fast. Nuestro proceso de entrevistas tiene que ser exhaustivo porque buscamos excelencia técnica y fit cultural. No podemos delegar las contrataciones por ahora. Es muy importante que seamos nosotras quiénes las hagan y que entrevistemos al menos una vez a todas las personas que entren. Contratamos siempre personas mejores que nosotras; personas que nos incomode contratar porque sentimos que son mejores en nuestro trabajo que nosotras; personas que nos daría orgullo presentar cuando presentamos a nuestro equipo. Sobre firing fast: es importante ser transparentes con las personas, comunicar lo que pensamos, poner accionables y deadlines. Desde la primera vez que pensamos que alguien no está funcionando hasta que activamos un plan de acción no pueden pasar más de un par de días.

- somos justas. Tomamos decisiones pensando en las personas. Si podemos ayudar, formar, dar más información, acompañar, lo hacemos. si estamos en duda y la acción no tiene un impacto negativo para la empresa y tiene un impacto positivo para la persona lo hacemos.

- somos transparentes y no burocráticas. Desarmamos burocracias cuando aparecen. Si alguien necesita algo de alguien, va y se lo pide (evitamos las triangulaciones de persona -> líder -> persona. La comunicación ideal es persona -> persona). Las burocracias y ocultar información nos vuelven más lentos. Lo único que importa es la velocidad.

- nos damos feedback rápido y en el momento. Generamos una cultura de decirnos lo que pensamos en el momento en que lo pensamos. Las fricciones se generan cuando pensamos cosas que no decimos. Nos damos feedback honesto entre nosotras y a los equipos que lideramos. La única forma de ganar como startup es tener un a-team y la única forma de tenerlo es con feedback constante (porque es la única forma de mejorar).

- las ideas no importan. una startup es un experimento. Ninguna idea importa y tampoco importa de quién viene. toda nuestra energía tiene que estar puesta en validar ideas (y la única forma de validar es con willingness to pay). Cualquier persona que interponga su ego a la importancia de validar ideas nos hace perder el tiempo y nos vuelve más lentos.

- la belleza importa y la calidad importa. No imitamos, no copiamos. Sí conocemos mejor que nadie lo que la competencia hace pero nuestra ejecución es 100 veces mejor. Pensamos ideas nuevas, somos creativos, mejoramos lo que existe. Empujamos para adelante a nuestra industria y a nuestros clientes con innovación y con calidad sin importar si los clientes o la industria lo están pidiendo. Nuestro norte es la excelencia, no lo que los demás están haciendo.

- trabajamos en problemas grandes e importantes. Hamming question.