how to have original thoughts in the age of ai

I want to explore why it matters to understand things and have original thoughts in the age of ai. why I care about this problem: people are using AI to shortcut thinking. what this means is that instead of using AI as a tool to think (to ask questions, work through problems), we are more driven to just give AI the problem and let it come up with a solution for us.

this might appear to be the most efficient way to solve a problem, but I will argue that in a human-centered economy we still need humans to process and understand information. i’d like to explore how AI tools can help us accomplish that, and how that might change in an ai-centered economy over the next few decades.


how do we think?

understanding problems and coming up with original solutions is something i’ve always cared about. i’m not very good at thinking off the top of my head so, with time, i’ve come up with some strategies to force myself into thinking and understanding. these are some of those strategies:

1) talking to others. an open discussion clarifies ideas and understanding and creates new ideas. sometimes called “brainstorming.”

2) writing it down on a whiteboard. i’ve always found this much better than writing on paper. it’s something about the ability to see everything at once that helps me understand problems more easily. 

3) making word maps. I remember, ages ago, trying to explain to someone how to think about a problem, and working with them on a word map to come to common ground. it's amazing how word maps can really trigger new ideas and lead us to new conclusions that we didn’t start with. i’ve always found it hard to think a couple of steps ahead, and mental maps really seem to help. 

4) writing/typing. starting with a clue and just letting the mind drift. I usually understand problems just by describing them and writing them down.


so how has AI been helping me come up with new ideas? by discussing ideas aloud, for sure. (talk mode is really an amazing tool.) but there is always a risk (at least for me). discussing a problem with AI means it will automatically try to give you the solution. and the thing with solutions that are given to us, is that we don’t fully process how we got there and so we don’t truly “buy” the solution.

think about times when you discuss a problem you are having with a partner, and they jump into solution mode. the frustrating part about that is that discussing the problem (complaining, ranting) is what's actually valuable about the exchange and not the solution itself. the act of talking about the problem is how we understand it and process it.

what does this mean for people that use AI as a replacement for their own thinking? my guess is that it means that they won’t be able to process and understand problems, and I argue that we need them to do that. (even if just letting AI give us the solution is more efficient.)


why do we need humans if AI can do it much better?

my reasoning is simple: we live in human-centered economies and democracies, meaning that the economic and political systems operate thanks to humans. it’s a human responsibility to make the final call on a policy. it’s a human’s work, and the salary they get for that job that moves the economy forward. in our current society, humans are the center of all systems, the decision-makers, and those responsible for how other humans live.

when the politician asks the AI how to work on a particular problem, without fully understanding its implications and only comprehending what the AI is saying at a superficial level, we risk harm to how other humans live. another way to think about that is that it is the AI that is understanding the problem (if so) and making the decision for the human.

one could argue that this is not an issue. if an LLM can process more content than a human and come up with a better solution than we can, we should use that tool. and I fully agree, but the thing is that LLMs are not there yet and are by no means deterministic thinkers that compare all possible outcomes before they propose a solution. until they do, we need humans to think, understand, and argue against ai.


the challenges of working out problems with ai

so, if we really need humans to think through problems, we need to come up with ways to collaborate with AI more efficiently. 

these should not be ways to make the LLM more efficient (although that is always a good thing) but ways in which we can train our personal models to work for us.

here are some of the challenges I see today when it comes to working out problems with ai—and some possible solutions:

1) AI jumping to solutions. this is the problem I stated originally. when the AI gives us the full solution to a problem, it’s hard for us to come up with a true understanding of the problem. something i’d like to test would be to give instructions to the model I use the most (sonnet 4, as of today) so that when I propose a problem it should never give me a solution but give me questions so I can keep thinking about it. if it does, it should never be just one but a series of solutions, forcing me to choose. 

2) AI writing a lengthy solution. one might think this is only a problem if people are not willing to read what the AI has written. but, as people say, the only good system is the one you use. we tend to not want to read all the content created by ai. a clear example of this comes with vibe coders. developers usually complain that the AI creates code prone to security issues. my counterargument to that is that it only does when you don’t read the code that it wrote. otherwise, you shouldn’t need to worry. my solution to this problem is obvious. train your model to answer in short answers or to write code in the minimal expression it can.

3) AI stating things as truths. from the days of gpt-3, we all seem to treat LLMs as prophets. the truth is that the LLMs we use are not giving us the most probable next word when answering a question but what the company that’s developing it has trained it to pick as an answer. in no way, even without that, would LLMs be deterministic thinkers. but the thing about humans and how we use LLMs is that we find it hard to challenge what the AI is suggesting, especially when it comes up with complete solutions (long texts, an ordered list, etc.). we are wired to believe that an answer stated with confidence shouldn’t be challenged.


my solution to this problem is that we should force AI to give us incomplete solutions. we need a way to force ourselves to think on our own about problems. my explanation as to why we need this comes from how the human mind works: our minds look for completeness, and what’s more interesting, they do so especially when they are faced with something that is incomplete. the mind wants to fill gaps.

for humans to really think about problems we need the AI to give us something we can iterate. think about mental maps. if I asked the AI to give me a full mental map (something like start from the word “poverty” and write all ramifications to how we could solve it), it would probably do a good job. but what’s rich about doing a mental map yourself is how, in the process, you come up with new ideas and explore them. 

what we need from the AI is the equivalent to writing down a mental map with missing words, incomplete paths, and empty cards for a person to fill out. we need that void, or incompleteness, to force ourselves into thinking.


what does an ai-economy look like?

i started by saying that while we live in human-centered economies we need humans thinking and understanding problems, and we went through some strategies we could use to use AI in a way that helps us accomplish that.

but what i’m really curious about is, what comes next? how do we move from a human-centered economy and political system to one that is able to delegate most of its work into systems much better than we are at understanding problems and processing large volumes of information?

what I could argue now is that this AI (whether it’s LLMs or something else) would need to become much better at coming up with deterministic solutions and that we need humans working out how to get AI to that next level.

what that AI economy might look like seems like a theme for another essay, so let’s just leave it at that.




aeropress

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.

cómo validaría el PMF de 15 ideas

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.

cómo pasamos de tener releases cada 6 meses a releases semanales

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á.


por qué antes nuestro proceso de release era lento

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 primeros meses de trabajo

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.


por qué empezamos a tener PMs

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.


cómo empezamos a pensar 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.


cómo recuperamos los releases semanales

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 :)

cómo pensar ideas para startups

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.


cómo buscar ideas

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).


cómo evaluar ideas para startups

TDB

what’s next for emails

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.


problemas que tienen hoy los clientes de emails

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.


whats next for email

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?


construyendo un cliente de emails para equipos de 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.



sobre tener biases

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.

S(t) = r

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


getting to no

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.


por qué enfocarse en las cuentas que necesitan una solución ahora

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.


getting to no: cosas que pregunto para evitar mi auto-bullshit

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.

algunos aprendizajes de vender b2b

- 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.


otros aprendizajes no relacionados al sales cycle

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).