John Wolpert CPO en Valuable · Autor de The Two But Rule
John Wolpert ha dirigido producto en IBM y ConsenSys y escribió The Two But Rule (Wiley). Una conversación sobre por qué tanto software, en Web3 y fuera de ella, se construye sin una razón para existir, y sobre la regla que él usa para combatirlo.

Kevin Hola a todos, este episodio va a ser una locura. Voy a hablar con John Wolpert, y por si no estás tan emocionado como yo: John Wolpert es un reconocido conferenciante, escritor y pensador en tecnología e innovación de negocio. Como CEO, ejecutivo de producto y asesor, ha estado en la vanguardia de los grandes avances tecnológicos, desde los primeros días de la web hasta el auge de la inteligencia artificial. A John se le conoce por fundar Flywheel, pionera en la industria del ride-hailing, y su trabajo en IBM lo convirtió en una figura clave en la evolución del software open source, de blockchain y de la IA. Ha cofundado consorcios globales de I+D y organismos de estándares de la industria, y su liderazgo intelectual en innovación abierta ha aparecido en Harvard Business Review. John ha dirigido incontables workshops de nuevos negocios y ha hablado ante la Unión Europea y el Parlamento de Australia en su misión de ayudar a las organizaciones a colaborar para resolver problemas difíciles. Estoy muy emocionado de tener esta conversación con John, y te lo digo en serio: cada vez, su sabiduría y su visión para atravesar tanta tontería son sencillamente increíbles. Así que, sin más preámbulos, empecemos.
Kevin Hola, John, gracias por recibirme. Bueno, antes de nada, has escrito un libro buenísimo, The Two But Rule, y como ya hemos trabajado juntos antes, lo empecé a usar desde el momento en que me lo explicaste, y de verdad tuvo un impacto en nuestro negocio. Así que, para empezar, como la mayoría de quienes nos ven quizá no lo conocen, ¿te importaría contar de qué va The Two But Rule y qué fue lo que te llevó hasta esto?
John Claro, Kevin, qué gusto verte, y gracias por invitarme. The Two But Rule es una idea bastante simple al principio. Aunque luego se pone profunda. La regla de los dos peros empieza simplemente con decir: pero eso no va a funcionar. Ser negativo. Alguien te presenta su intención de hacer algo, superar un problema, aprovechar una oportunidad, tiene una idea, ¿y qué decimos? Ay, pero eso no va a funcionar. Pero eso no me gusta. Pero no nos lo podemos permitir. ¿Verdad? Tú lo has vivido. Yo lo vivo a veces hablando con mi mujer. Pero no nos lo podemos permitir. Pero no podemos hacer esto. Pero, pero, pero, pero, ¿no? O sea, hemos vivido en una cultura. Desde luego, como Gen X, yo viví una cultura muy fuerte del pero único. Llegaban los boomers y nos soltaban su bomba de un solo pero: pero no queremos hacer eso. Pero tú calla y haz tu trabajo. Ese tipo de cosas. Y eso no nos gustó mucho. ¿Y qué hicimos? Pues una cultura sin peros para todos ustedes. Lo siento. Porque si hay algo que mata el momentum más que una cultura de un solo pero, es una cultura sin peros. Entonces tienes una cultura sin peros donde la gente tiene miedo, o no se siente segura, o ni siquiera sabe que puede cuestionar una idea. Tenemos todas esas frases dando vueltas, como las frases de no matar ideas en el brainstorming. No hay ideas malas. Pues esa sí que es una idea malísima. Claro que hay ideas malas. Deberíamos amar nuestras malas ideas.
John La mitología esa de que hay emprendedores tercos y obstinados que persiguen su idea original a pesar de la oposición: quizá pasa de vez en cuando, pero en mi experiencia siempre hay una historia más profunda detrás de esa mitología donde, pues no, su idea era terrible, y la fueron evolucionando cuando se dieron de frente con la oposición. Imagínate la misión Apollo 13, cuando la tripulación estaba en peligro y el módulo de mando explotó. Su primera idea fue dar la vuelta a la nave, encender el motor principal y volver a la Tierra de inmediato. E imagínate qué habría pasado si, cuando un ingeniero dijo, pero eso no va a funcionar, el motor probablemente está dañado, alguien hubiera dicho: ay, no seas tan negativo. Pues sí, eso habría matado a la tripulación. Luego resultó que descubrieron que, efectivamente, habría sido una muy, muy mala idea. Así que en vez de eso dijeron: pero podemos usar la luna de honda, aprovechar un montón de gravedad y traerlos de vuelta por ahí. Y después vino toda una serie de peros. Los filtros de CO2 no funcionan en el módulo lunar, pero podríamos improvisar una máquina de Rube Goldberg para arreglarlo. Hay tantos peros, ¿no? La vida es una cadena de peros.
John Pero eso no va a funcionar. Pero funcionaría si. Pero eso tampoco va a funcionar. Pero funcionaría si. Y en mi experiencia dirigiendo laboratorios de innovación, organizaciones de investigación y equipos de producto, cinco rondas de la regla de los dos peros son una buena receta para llegar a algo innovador, quizá una patente o dos. Y eso lo he vivido. Así que esa es la regla de los dos peros en pocas palabras. Debajo hay mucho sobre intenciones y sobre escuchar las necesidades detrás de por qué alguien quiere hacer algo y por qué tú no quieres hacerlo, o cuáles son las necesidades que alimentan tu necesidad de oponerte. Y luego encontrar una manera creativa de cuadrar esas cosas. Dices: pero yo no quiero hacer eso, pero entiendo por qué tú quieres hacerlo y entiendo por qué yo no quiero. ¿Y dónde podemos encontrarnos a mitad de camino y cuadrar esas dos cosas?
Kevin Qué explicación tan bonita. Y una cosa que me encanta de esto es que no solo sirve para discusiones, ¿verdad? También sirve cuando hablas contigo mismo, cuando estás evaluando algo, porque te obliga a tener la mente más abierta frente a un problema concreto, por decirlo así. Entonces de verdad tienes que pensar: bueno, realmente no creo que sea bueno. Pero. ¿Bajo qué circunstancias podría ser mejor, o lo que sea? Y ese cambio de chip a mí también me ayudó mucho.
John Sí. Creo que la mayoría vivimos la vida con miedo a nuestros peros. Yo me he sentado en esa silla de ahí, en mi sillita de pensar, y he huido de mis propios peros tantísimas veces. O sea: ay, quiero hacer esto. Quiero construir esto. Quiero probar esto. Pero. Y entonces salgo corriendo. Y pierdo un montón de tiempo. Y si estoy atento, me doy cuenta de que estoy ahí congelado, con miedo de mirar esos peros a la cara. Y escribí el libro sobre esto, ¿eh? Pero en una cultura de dos peros, cuando estás habituado a los dos peros, dices: ah, mira, gracias por eso, amigo. Qué buen pero, muéstrame todos tus peros. Y a esto lo llamamos momentum thinking, que es el término clínico. Pero yo también quería que esto entrara en la cultura de más equipos, más empresas, porque si la gente espera tu segundo pero y tú estás habituado a darlo, te van a dar una oportunidad con tu primer pero. En cambio, es algo muy vulnerable presentar un, oye, quiero hacer esto, y que alguien te diga: pero eso no va a funcionar.
John Me acuerdo de un equipo que dirigía en IBM donde pasó eso. Una contratación nueva se animó con un, oye, ¿y si hiciéramos esto?, y un ingeniero del equipo soltó: pero eso no va a funcionar. Mic drop. Y entonces yo dije: pero funcionaría si. Ahora, idealmente el ingeniero lo habría dicho él solo. Yo no tendría que empujarlo. Así que le pregunté: pero funcionaría si. Y se quedó mirando al techo y dijo: pero funcionaría si la gravedad fuera distinta. Y no pasó ni un minuto cuando otro ingeniero saltó de su silla con algo buenísimo, tipo: ¿y si hiciéramos esto? No cambiamos la gravedad, pero le dio al segundo ingeniero un contexto nuevo, una manera nueva de pensar el problema. Y eso acabó en un par de patentes y en un proyecto que llamó la atención del CEO de IBM. Así que sí, eso es momentum thinking. Lo llamé The Two But Rule porque me pareció más pegadizo y más probable que la gente se pusiera a darle vueltas. Porque una vez que has visto tu pero, ya no puedes dejar de verlo.
Kevin Lo bueno es que justo me estoy acordando de Jeff Bezos diciendo que tienes una gran cultura de empresa si, digamos, la última contratación, el ingeniero o la persona más joven y con menos experiencia del equipo, puede ganarle con datos a la persona más senior. Y creo que esa también es una buena forma de inducir esto de alguna manera, ¿no? Porque cualquiera puede venir también con un pero medio tonto, ¿verdad? Que es parte de tu estrategia. Y eso como que abre las puertas para que cualquiera aporte, ¿no?
John La regla es que tienes que traer un segundo pero. No hace falta que sea especialmente bueno. Y luego el equipo tiene que recordar que también puede aplicarle los dos peros a eso: bueno, pero esa no es muy buena idea, pero lo sería si. Y luego, pero eso tampoco. Si lo sostienes el tiempo suficiente, acabas llegando a algo. Justo el otro día tuve una conversación en familia con mi mujer, hablábamos de esto, y me llevé un recordatorio. Se me ocurrió una segunda idea malísima, y ella como: eso es malo. Lo sé. Y yo: claro que lo es. De eso se trata. Es una mala idea, sin duda. Por eso la dije. Y ella: ah, claro. Sí. Y entonces encontramos una solución muy buena a un problema con fiestas de cumpleaños. Ese problema en concreto, pero da igual cuál sea. Puede ser ciencias de la vida, o cambio climático, o un cumpleaños familiar. Así que solo con habituarte a eso, y con tener una cultura que lo espera, todo se vuelve más seguro.
John Pero has dicho algo sobre cómo esto empodera a los empleados más nuevos, más jóvenes. Se habla mucho de crear espacios seguros para los empleados, para los que tienen menos experiencia. Pero me parece que lo contrario es lo interesante de mirar hoy. Es inseguro. Para la mayoría de los managers de cualquier empresa de cierto tamaño es seguro decirle a cualquier empleado que su idea no es buena. Y hay un libro de Amy Edmondson, que es profesora en Harvard, un gran libro, de hecho varios grandes libros suyos, y ella está muy metida en esta idea de la seguridad psicológica, que tiene mucho sentido, pero se puede malinterpretar como: oye, tienes que hacer que todo el mundo se sienta seguro y validado y ese tipo de cosas. Y yo digo: no, tu idea es una mala idea. No te hago ningún favor al decirte que no es una buena idea.
John El ejemplo que se suele poner es: hay un par de casos donde un piloto senior, digamos, no escuchó al piloto junior, y ocurrió un desastre. Pero de lo que no solemos hablar es: ¿qué pasa con el caso en que el piloto senior ignora su propio criterio, fruto de años de experiencia, se queda con la idea menos buena del piloto junior, y eso causa un desastre? Así que no puedes aplicar eso de forma general. ¿Cómo hacemos que sea seguro para una persona senior decir: oye, gran idea, pero no tan gran idea, pero esto no va a funcionar? Y una manera de hacerlo es decir: pero esto no funcionó en los noventa, pero esto fue lo que pasó, así puedes intentarlo otra vez y quizá esquivar ese error. Es difícil presentar tu pero ante cualquiera, seas senior o junior, creo yo.
Kevin Qué interesante. Bueno, hablando de dónde aplicar esta regla de los dos peros, estoy bastante seguro de que hay ciertas áreas de tu vida o de tu carrera donde la regla tiene un mayor, digamos, donde es más impactante que en otras. ¿Cuál es tu experiencia con eso?
John Creo que funciona mejor en entornos de equipo donde intentas pelearte con un problema enredado, donde no hay una respuesta clara. Tienes que ir a la izquierda o a la derecha, y no hay forma de saber con certeza hacia dónde. Y de nuevo, el gran pero tonto para eso es: oye, tú quieres ir a la izquierda, pero yo no quiero ir a la izquierda, pero podríamos ir a la derecha. O puedes decir: pero podríamos hacernos crecer unas piernas gigantes y larguísimas e ir a la izquierda y a la derecha a la vez. Y es una tontería, pero le dice a la otra persona que, oye, la escuchaste, y que hagas lo que hagas, lo van a hacer juntos. Así que hasta ese pero tonto tiene su utilidad. La otra cosa muy útil, y creo que esta quizá es la misión, es ayudar a los poneperos. ¿Cuánta gente habrá viendo esto ahora mismo que siente que la van a expulsar de la isla, o que se está convirtiendo en un paria o en una Casandra, alguien a quien nadie escucha? Ya sea porque se les ve demasiado negativos porque se meten con un montón de peros, o porque no se sienten cómodos presentando sus peros, y dejan pasar un montón de malas ideas y se vuelven ineficaces. Hay mucha gente en ambos lados de eso que está en un lugar terrible. O sea, las consultas de salud mental deben estar llenas de poneperos.
John Gente de un solo pero, ¿no?, porque no es un trabajo divertido. A la gente no le gusta oír pero, pero, pero. ¿Y si le damos la vuelta y salvamos al poneperos, y decimos: mira, sí, él es nuestro poneperos oficial designado, porque siempre viene con dos peros? De hecho, si haces lean startup, en el libro hay una historia de cómo se nos escapó un truco con un experimento que estábamos corriendo en el mercado. Y se nos escapó porque validamos nuestras suposiciones en vez de usar ese experimento para buscar los peros adicionales que estaban ahí fuera, acechándonos. Y se nos pasó uno grande, y fue un error costoso, porque estábamos tan contentos de que una parte del experimento validara lo que pensábamos, en vez de decir: ya, ¿pero qué más va a salir mal? ¿Qué más nos está diciendo este experimento sobre los problemas de este enfoque? Y se nos pasó uno muy gordo. Si hubiéramos tenido un poneperos designado en el equipo, el chief negativity officer, si pudiéramos celebrar a esa persona, le diríamos: sí, nos encanta que seas bueno encontrando problemas. Pongamos todos esos peros en una pared. Y al final del sprint, emparejémoslos con un segundo pero, y luego encontremos aquellos con los que podemos hacer algo o que podemos explorar, y vamos al siguiente sprint. Creo que eso sería bastante más divertido y bastante más productivo.
Kevin Sí, lo estás haciendo bien. Y te da una métrica, ¿no? Pero los que no llevan tanto la contraria tienen que venir con algo. Y los que, como dices, llevan demasiado la contraria, quizá también saben: tengo que venir con lo contrario. Así que es, como dices, momentum thinking, y ahí está lo bonito.
John De hecho, esto no está en el libro, pero trabajando después en consultoría, alguien lo señaló, y me parece brillante. Si eres una persona que se mete demasiado rápido en la conversación, ¿no?, no sé tú, pero cuando siento que he saltado demasiado pronto a una conversación, normalmente es porque me preocupa olvidar lo que quería decir. Algo que has dicho dispara algo en mi cabeza, sea negativo o no. Y eso lleva a, ah, ya sabes, te conviertes en esa persona que salta. Hay mucha gente así. Hablaba de esto con alguien y me dijo: sí, yo soy de Nueva York, eso es lo normal. Así que hay diferencias culturales de timing. Pero en un equipo, normalmente necesitas darle a la gente espacio y tiempo, y tienes que dar con el ritmo correcto. Y para algunas personas eso es muy difícil. Hay un montón de gente con TDAH a la que le cuesta muchísimo dar con el ritmo, con el ritmo de una reunión con más de una o dos personas.
John La observación era que, si esperas a tener formado tu segundo pero antes de soltar el primero, no se te va a olvidar el primer pero, porque estás formulando el segundo y eso genera un montón de actividad neuronal. No se te olvida ese primer pero. Puedes esperar. Puedes llegar al final de la reunión. Ahí seguirá. Y si te habitúas a eso, te da tiempo. Te hace más reflexivo. Te abre a escuchar: bueno, el segundo pero tiene que salir de las necesidades de esta otra persona. ¿Qué necesita de verdad? Okey, bueno, en realidad lo que no está diciendo es que lo que de verdad necesita es que la escuchen en este algo. Okey, pero podríamos hacer eso, ¿no? Pero ahora tienes algo, y eso dura. Dura hasta el final de la reunión, o incluso después de la reunión lo vuelves a sacar.
Kevin Una pausa rápida. Si pudiera pedirte un solo favor, sería que te suscribas a este canal, porque ayuda a nuestro canal más de lo que te imaginas. Y ya sabes, cuanto más grande se hace el canal, más grandes son los invitados. Así que muchas gracias por vernos, y sigamos con el episodio.
Kevin Bueno, está claro que este método se puede aplicar de muchas formas. Me pregunto, en cuanto a product management, al desarrollo de producto en sí, construir o lanzar un producto es un proceso largo, larguísimo. Después del lanzamiento, sigue, ¿no? ¿Cómo cambia quizá la aplicación de este enfoque a lo largo del proceso? ¿O es sobre todo para discusiones, y cuando hay algo tipo disputa, entonces es genial para zanjarla o algo así?
John Bueno, desde luego es genial para el alineamiento. Como sabes, y yo desde luego lo sé desde hace muchos años, no hay equipo que no pase por una crisis de alineamiento cada sprint. Es algo que simplemente pasa. Los humanos se desvían, o empieza esa especie de deriva genética mental respecto a lo que fuera la idea original de alguien. Y esto pasa con tantas personas como haya en el equipo. Así que para el alineamiento, desde luego, sirve. Dices: bueno, pero estoy empezando a pensar estas ideas nuevas, pero queremos mantener el rumbo. Pero podemos mantener el rumbo y abrazar las ideas nuevas si, ¿ves?, ahí lo tienes. Estás aplicando las necesidades. Necesitamos mantener el rumbo. Me da ansiedad pensar en ir zigzagueando por todas partes. No queremos ser esa empresa. Pero al mismo tiempo, necesitamos ser receptivos. Eso es un problema enredado, o un wicked problem, como lo llaman. No hay respuesta correcta. Es equilibrio. Los problemas de punto de equilibrio son todos buenos problemas para los dos peros. Así que ese es un lado. El otro lado, y mencioné el lean startup, hay un capítulo que se llama Leaning Into Your But, donde, en vez de los cinco porqués, es algo así como los cinco peros. En los proyectos lean tienes que apoyarte en tu pero. Eso es más bien experimentación.
John Y luego la otra parte que es realmente importante para product management, creo, tiene que ver con el producto en sí. Por ejemplo, ahora mismo estoy fascinado con un problema de dos peros muy potente, que es: necesitamos compartir, pero no podemos compartir. Llevo fascinado con este problema casi 30 años, creo. Seguro que 25. El problema de necesito-compartir-pero-no-puedo-compartir aparece en todas partes. Eres una startup. Estás bastante seguro de que necesitas un socio. No puedes decírselo al socio potencial. Para empezar, quizá ni siquiera sabes cuál es el socio ideal, pero no puedes publicar en LinkedIn que necesitas esto, porque estás exponiendo tus intenciones. Puedes inventar algo y contárselo a todo el mundo, patentarlo, lo que sea. Da mucho miedo contarle a la gente tus intenciones. Oye, tenemos la intención de hacer esto, y tenemos un hueco entre lo que queremos hacer y lo que podemos hacer. A las empresas esto les resulta extraordinariamente aterrador, y con razón. Las intenciones no se pueden proteger. Y las intenciones son los verbos de acción de la innovación. O sea, los inventos son los sustantivos. Lo que yo pienso hacer con algo es el verbo de acción. Aquí está mi invento, este bolígrafo. Te lo puedo clavar en el ojo, y ahora es una innovación disruptiva. Y no puedo contarte eso, ni a ti ni a nadie, antes de hacerlo, o no te vas a quedar quieto mientras lo hago.
John En ese marco, eso es criptografía zero-knowledge por un lado, y por otro usamos headless vectors, para poder encontrar oportunidades de coordinación sin exponernos los datos directamente unos a otros. Creo que es un espacio interesantísimo, donde ni siquiera el proveedor SaaS tiene de verdad tus datos, pero aun así puede encontrarte conexiones y permitirte coordinarte, en una cadena de suministro, en la búsqueda de ejecutivos. Todo esto es: necesitamos compartir. Soy un CEO. Quiero irme de mi empresa. Tú eres el consejo. Quieres despedir a tu CEO. Ninguno de los dos puede decírselo a nadie salvo a nuestro reclutador. Eso pone al reclutador en una posición muy delicada.
Kevin Sí. Ahora déjame aplicar tu regla de los dos peros: ¿pero de verdad es un dolor tan grande? Porque si miras LinkedIn, ya puedes ocultar, por ejemplo, tus intenciones frente a tu empleador actual. Claro, pueden enterarse si quieren, ¿no? O sea que no es a prueba de balas, pero ¿no es suficiente, básicamente, para resolver ese dolor?
John Sí, lo es. En ese caso concreto, claro, siempre estás sudando un poco por si alguien filtra esos datos. Eso nos preocupa. Entonces sí, en estas situaciones de compartir necesitas confiar en un proveedor, ¿no? Un reclutador, un headhunter de ejecutivos, un SaaS, un LinkedIn. Y sí, se convierte en un problema trivial si puedes confiar en el intermediario. Es como cuando estabas en la secundaria y estabas enamorado de alguien, y una amiga suya salía con tu amigo, pero sabes que tu amigo habla más de la cuenta, y sería comodísimo poder decirle: oye, ¿me pones al lado de esa persona en la cita cuando vayan al cine? Y tú piensas: no, seguro que me lo arruina. O sea, es una situación muy delicada.
John Pero hay otros más profundos, como la cadena de suministro, por ejemplo, donde necesitamos entender el riesgo de la cadena, el riesgo de proveedor único, cosas así. Y los proveedores no van a soltar nada, da igual cuánto poder tengas. Y he estado en mil tipos de proyectos como este, donde una empresa muy poderosa creía que tenía poder suficiente para que todos le dieran sus datos. Y resulta que no, que no quieren darle los datos. Entonces, ¿cómo nos coordinamos? Pero necesitamos saber dónde están todos los rábanos malos, o dónde está toda la contaminación, o quizá hubo un caso de envenenamiento o de salmonela o algo así. O no sabemos por dónde se nos va a frenar en seco la línea de producción, porque un proveedor de un proveedor de un proveedor de un proveedor es un contrato de fuente única que sale de, digamos, China. Y hay una disrupción en esa cosa concreta, y ahora nuestro avión lleva tres meses de retraso y cientos de millones de dólares por encima del presupuesto, solo por una piececita diminuta cuatro o cinco capas adentro de la cadena de suministro. Poder visualizar eso, encontrarlo, predecirlo y gestionarlo: si pudieras tener todos los datos, es un problema trivial. El problema es que las empresas no te los quieren dar. Así que me parece un problema de dos peros realmente interesante.
John Claro. Pero las empresas, ya sabes, acepta el hecho de que las empresas tienen necesidades de no hacerlo. Si eres una empresa de granjas de pollos, no quieres que la cadena de supermercados que tiene poder sobre ti sepa dónde están todas tus granjas. Pero necesitan saber si hay una contaminación. Y tampoco queremos tener un gran honeypot de datos en la cadena de suministro. Cuando estaba en IBM, lo intentamos muchas veces a lo largo de los años, y resulta que a nosotros tampoco nos quiere dar los datos nadie. Entonces, ¿cómo no entregas los datos, pero aun así te coordinas? Es un problema interesante.
Kevin Sí, bueno, claramente es algo en lo que se lleva trabajando muchísimo tiempo. Y ya lo vemos en muchas cosas, ¿no? Con ZK, como mencionabas, y todos esos proyectos de datos comercializados, proyectos de compartición de datos que hay por ahí. Está pasando mucho en ese espacio, seguro.
John Sí, o sea, pensábamos que blockchain, por eso me metí en blockchain hace años, pensábamos que podía ser un enfoque. Resulta que es un antipatrón. Poner tus datos en una gran colonia nudista digital es más o menos lo contrario de lo que quieres hacer con ese tipo de problema. O sea, incluso con ofuscación, en el mundo de la IA, la IA te va a identificar si pones tus transacciones en una blockchain. No cometan delitos en blockchains, chicos. Los van a encontrar. Usen mixers, igual los encontraremos. Y ese enfoque concreto tiene problemas de escalado. Pero el espacio del problema, como muchas cosas en Web3, el problema es legítimo. La solución, resulta, para ese conjunto de problemas: sí, sí queremos, no queremos quedar atrapados con un proveedor. No queremos que Facebook sea nuestro dueño, o lo que sea.
John Queremos poder mover nuestros datos sin perder nuestras conexiones, nuestro SEO. No queremos que los buscadores nos pierdan. Bueno, una manera: Substack. Tengo mi propio dominio. Substack tiene dominio personalizado. Les pagué 50 dólares. Y ahora, si moviera todos mis artículos de Substack a otro sitio, es solo un redirect 301. No necesité blockchain para eso. Es solo una política que tenía la empresa de que no vas a quedar atrapado. Eso lo hicimos en los noventa con los números de teléfono en Estados Unidos, y creo que Europa también lo hizo, donde tenemos portabilidad numérica. Simplemente lo decidimos por regulación. Dijimos: sí, todas las compañías telefónicas tienen que permitirte llevarte tu número si te cambias a otro operador. Antes de 1997 no podías hacer eso. No usamos una blockchain para arreglarlo. Simplemente decidimos que era algo importante. Así que el lock-in, creo, sí importa. La descentralización por la descentralización misma, ahí es donde creo que nos equivocamos. Creo que lo que tenemos que hacer es centrarnos en los problemas, en por qué tenemos esos problemas, en cuáles son las necesidades que intentamos resolver donde creemos que Web3 o blockchain lo solucionaría. Y luego decir: ya, pero no escala, pero en realidad es medio antipatrón, pero igual podríamos lograr lo que necesitamos aunque no usemos una blockchain.
Kevin La tecnología más simple para tu conjunto de problemas, tiene todo el sentido. Bueno, como dices, cuando se trata de compartir datos, de estas cosas en concreto, totalmente. Estoy de acuerdo con muchas cosas. Claro, yo vendo blockchain, como sabes, pero como puedes ver, soy muy crítico con los casos de uso para los que se aplica. Para muchas cosas simplemente no tiene sentido.
John Yo sigo pensando que blockchain, las grandes listas enlazadas públicas, son un buen sitio donde guardar hashes y pruebas. Scott Stornetta lleva haciendo eso desde 1995 con la sección de clasificados del New York Times. Es un caso de uso perfectamente válido. Necesito alguna forma de llegar al fondo de esto. Necesito saber que este hash de unos datos que tomé en algún momento del pasado, que los datos no han sido manipulados. Y necesito saber que el hash en sí no ha sido manipulado. Así que necesito algo realmente resistente a manipulación. Y si es un hash, bueno, de un hash no sacas muchos datos. Así que no me molesta la idea de soltar ahí hashes, o un árbol de Merkle lleno de hashes, o la cabecera de un árbol de Merkle, como Mina. Mina todavía me gusta bastante. Me encantaría hacer un fork de Mina y encontrar una manera de hacer Mina sin un token de apuestas alimentándola. Porque, ya me conoces, eso no es lo mío. Un amigo mío ideó una forma interesante de usar acciones, acciones legítimas, como forma de staking. Creo que lo llamamos StockChain o algo así, donde no usas un token de criptomoneda ni intentas convencer a la gente de que la moneda va a subir para asegurar la red. Podrías hacer staking de acciones en una especie de sistema tipo fondo mutuo. Y eso funcionaría. Eso funcionaría de verdad.
John Entonces, si pudieras correr una Mina sin crypto, porque a mí el crypto no me gusta, y pudieras operarla de tal forma que pudieras decirle a cualquiera: aquí está mi prueba de Merkle del estado de los datos compartidos que tenemos. Yo tengo unos datos en mi sistema de compensación. Tú tienes unos datos en tu sistema. Y vamos a correr una prueba de que estos datos que tenemos son los mismos, de que mi crédito es tu débito, y de que las reglas que usamos para llegar ahí son correctas y siguieron un conjunto de reglas. Y puedo dar fe de eso, y puedo mandarte la prueba de Merkle. Y lo único que tienes que hacer es comprobar la cabecera de una blockchain de Mina, y podrías decir: sí, definitivamente tienes ese débito y ese crédito, y no le prestaste al tipo por encima de la ley de usura de Texas, así que sí, te aseguro el préstamo. Y no tuve que darles los datos para hacerlo. Creo que esa es una blockchain perfectamente válida y usable. Solo que es medio aburrida. Desde luego no hace ricos a los degens del crypto, pero es un uso bastante bueno de blockchain, porque las blockchains sí pueden escalar para ese caso de uso.
John ¿Ser el sistema monetario mundial? Jamás lo va a lograr. Cuando consigamos que una blockchain haga eso, también tendremos warp drive. Y no es una hipérbole. Bueno, no sé, seamos honestos. Pero podríamos llamar a Leslie Lamport, el padre de los sistemas distribuidos, y estoy bastante seguro de que diría que sí, que la causalidad es la causalidad, y que la velocidad de la luz es un límite. Así que si puedes romper la causalidad y conseguir de verdad que un singleton replicado escale, pues genial. Pero entonces también podríamos romper la velocidad de la luz.
Kevin Eso que mencionabas de usar acciones, básicamente, me recordó a un montón de esos proyectos que intentan usar al menos un activo distinto en otra chain como, digamos, proof of stake. Puedes ver cómo va el debate, pero, como gran mecanismo de consenso, creo que la tecnología ya está ahí para ese tipo de casos de uso, ¿no?
John Sí, pero ya estás de vuelta en el laberinto, ¿no? O sea, de hecho, piensa en la banca corresponsal. Es un sistema descentralizado. Están todos esos bancos, y todos tienen su propio ledger. Y Swift y otras cosas intentan mantenerlos sincronizados. Y en vez de un banco central, ahora tienes una blockchain central. Están gestionando bridges, que es donde pasan todos los problemas del crypto, en los bridges, o muchos de ellos. Y claro, lo que hemos aprendido es que, aunque puedas decir que, digamos, Bitcoin no ha sido hackeada y la resistencia a manipulación está probada, desde luego ha habido muchísimo crimen y hackeo en los bordes. Así que eso no lo resolvió. Un montón de fraude igualmente, porque al final del día la blockchain tiene que tocar el mundo real en algún punto. Y entonces, sí, vuelves a lo que yo siempre encontré en ocho años de blockchain, que era que cada vez que creías que estabas saliendo del laberinto y habías resuelto el problema, habías descubierto algo, te volvía a meter directo en el laberinto.
John O sea, intentábamos alejarnos de la centralización. Estamos entregando un nivel aterrador de centralización en nombre de la descentralización. La hegemonía del crypto es real. Como hemos visto, los precios están inflados, mantenidos por gente que puede permitirse hacer wash trading y algunas cosas más para sostenerlos ahí arriba. Un montón de manipulación. Todas las cosas de las que queríamos huir, las estamos entregando a raudales en nombre de huir de ellas. Eso no me gusta. Así que ese es el problema que yo he encontrado con la blockchain: cada vez que intentas mantener los principios de blockchain, acabas sucumbiendo justo a las cosas que dices. Ah, sí, será más rápido si tenemos menos descentralización. Sí, Solana es más rápida que Bitcoin y más rápida que Ethereum, pero también es menos segura. Estos trade-offs son fundamentales. ¿Una lista enlazada está bien? Claro. Sí. Me gustan las listas enlazadas. ¿Pero creo que hay que descentralizarlo todo simplemente por descentralizarlo? No. La herramienta correcta para el trabajo correcto, como dices tú.
Kevin Bueno, como decía, la descentralización es una herramienta en sí misma, ¿no? Si la necesitas por alguna razón. Definitivamente creo que hay ciertos casos, ya sabes, piensa en, ese es mi pero básicamente: gobiernos no tan estables, países no sostenibles, justo esos casos límite, ¿no? Donde realmente no puedes confiar en ellos.
John Y, no sé, no sé qué me estás diciendo, pero aquí está mi pistola, ¿no? La pistola gana, ¿verdad? Entonces, ¿eso de verdad lo resuelve? De nuevo, aquí es donde la criptografía zero-knowledge y la identidad digital, definitivamente, solo que no necesitas una blockchain para eso. O quizá puedes anclar atestaciones y DIDs y demás. Quizá está bien. Pero al final del día, lo que estamos haciendo ahora mismo en Estados Unidos es implementar licencias de conducir digitales y ese tipo de cosas, y todo sale directamente del secure enclave de tu teléfono, sin blockchain de por medio. No necesitas nada de crypto para hacerlo. Entonces sí, identidad digital, identidad digital segura frente a alguien que quiera identificarte, claro. Definitivamente no quieres que el malo sepa que eres tú. Periodismo. Pero no es una panacea para eso. O sea, en lo que tenemos que mantenernos enfocados es en el problema. Que maten a menos periodistas, ese es el problema. Ese es el problema a resolver. No es: oye, blockchain, a ver si podemos salvar periodistas con blockchain.
John Hay una persona muy agradable en el espacio blockchain que me cae muy bien en muchos sentidos, pero me volvía loco con una frase. Decía: vamos a salvar el mundo con blockchain. Y yo: ¿podemos parar con esto? ¿Podemos empezar simplemente con: salvar el mundo? Y centrémonos en eso. Céntrate solo en esto. Salvemos el mundo. O sea, ahí me apunto del todo. Nos ponemos un montón de restricciones si decimos: con blockchain.
Kevin Eso estuvo gracioso. O sea, eso lo ves con muchas cosas, ¿no? No es solo blockchain. También la IA, el content computing, todas estas cosas, ¿verdad? Lo vemos cuando la gente nos llega con proyectos: quiero usar Web3, quiero usar IA, quiero usar esto. Pero en cambio, muchas veces tienes que tachar todo eso y preguntarles: ¿qué quieres lograr? ¿Quieres levantar dinero con esto? ¿Quieres conseguir tu primer cliente de pago? ¿Quieres eso? Entonces intentemos encontrar la manera de gastar la menor cantidad de tiempo y de dinero para llegar ahí.
John ¿Sabes?, cuando estaba en IBM y arrancamos Hyperledger y Hyperledger Fabric, yo era mi peor enemigo. Era raro. Podía sacar una venta de un banco grande solo a base de ponerle objeciones. Les decía: ¿por qué están usando esto? Y es mi producto, ¿no? Y luego les decía: ¿por qué están usando mi producto? No deberían. Y ellos: ah, ahora sí que lo queremos usar. Y lo gracioso es que, si me hubieran dado una moneda por cada vez que alguna empresa, normalmente una grande, el equipo, y yo los desafiaba con esto, una moneda por cada vez que decían: bueno, en realidad no lo necesitamos, pero llevamos 10, 20 años intentando resolver este problema, y si lo llamamos blockchain, el jefe lo financia. O sea, eso ya no pasa. A nadie le importa. De hecho, llamar blockchain a algo mata el proyecto. Pero sí, creo que eso puede ser lo que mate al crypto más rápido que cualquier otra cosa: el crypto necesita hype.
John El crypto no puede sobrevivir. Si una blockchain pudiera soportar un caso de uso de efectivo, efectivo global, diría que tendría otro punto de vista. Pero sabemos que no puede. Y no me hables de Lightning. No lo va a lograr, no. Porque, de nuevo, el problema es que el costo marginal de una transacción en cualquier tipo de blockchain es distinto de cero, mientras que incluso en el peor de los sistemas bancarios, el costo marginal de una transacción tiende a cero. Los bancos te cobran comisión porque pueden, no porque tengan que hacerlo. Y esos son problemas de base con el caso de uso del efectivo. Si pudiera ser efectivo, diría okey. O si dijéramos que cada token es un valor financiero de verdad, también estaría de acuerdo. No me gusta desplumar a la abuela. No me gusta reabrir todos los mismos vacíos legales que teníamos en el siglo XIX, que desplumaron a la abuela, que nos llevaron a crear el tipo de regulaciones que hizo la SEC en el 33 y el 34, que por cierto siguen vigentes hoy. Pero si dijéramos: sí, cada token es en realidad un contrato de inversión, y vamos a llevar el registro de ese contrato de inversión en una blockchain, no tengo ningún problema con eso. Solo llámalo por su nombre. Es un contrato de inversión.
Kevin Algo muy interesante ahora, que me llevó a un punto en el que en realidad nunca había pensado. Qué pasaría si, creo que es una tesis que te puede gustar. Los bancos pueden cobrar esas comisiones, ¿no?, que muchas veces son altísimas. Los bancos, por un millón de dólares, tan alto como comprar un paquete de chicles con Bitcoin y que la transacción cueste 200 dólares. Si transfieres sumas enormes de Estados Unidos a, no sé, China o donde sea, o solo dentro de Europa, ya pagas una buena fracción de eso. Y estoy pensando: ¿qué pasaría si, solo por el objetivo de hacer más eficiente la infraestructura financiera, el simple hecho de que blockchain exista obliga a los bancos a bajar sus comisiones?
John Sí, podría ser. Si al final el crypto se convierte en una especie de dinero de la dark web, y no es algo con lo que trate la mayoría de la gente, pero le metió un susto de muerte al sistema bancario y obligó al sistema bancario a ponerse las pilas, sí, no hay nada de malo en eso. Y hay un libro muy bueno para leer si a alguien le interesa este tema, se llama Moneyland. Moneyland es un libro muy bueno. No va de blockchain, pero si miras las fechas de cuándo una cosa llamada FATCA empezó a hacer muy difícil usar bonos al portador suizos, bonos al portador no rastreables, para mover dinero entre fronteras con impunidad: eso fue más o menos de 2008 a 2014. ¿Y qué estaba surgiendo de 2008 a 2014? Exacto.
John No creo que Bitcoin sea efectivo digital. Creo que son bonos al portador digitales de precio variable para gente que tiene, legítimamente o no, una necesidad muy fuerte de mover grandes fajos de dinero entre fronteras con pseudoimpunidad y evitando impuestos. Ese sí es un buen caso de uso, porque es un número relativamente pequeño de transacciones, de montos grandes. Y la cosa es que el tipo de gente que necesita eso muchas veces no es el tipo de gente que quieres conocer demasiado bien.
Kevin Bueno, ¿qué te puedo decir? Nadie lo sabe con certeza. Al menos yo siempre intento mantenerme abierto. Pero, como mencioné antes un par de veces: elige la tecnología donde tenga sentido. Blockchain, totalmente de acuerdo contigo el 99, 98 por ciento de las veces. Y eso se lo decimos también a nuestros clientes: no tiene sentido, ¿no? O es una solución en sí misma, para sus propios problemas. Pero, como también mencionaste, quizá la identidad descentralizada podría ser. O al menos, yo considero que ZK es parte de blockchain, por ejemplo, ¿no?
John Ojalá nos alejáramos de eso. ZK necesita vida propia. ZK funciona. Es caro computacionalmente, pero no hay nada en las leyes de la física que le impida cumplir su promesa, que es que puedes probar cualquier cosa dentro de NP, o de IP, bajo conocimiento cero. Algunas cosas son más difíciles que otras, pero nada de eso es fundamentalmente imposible. Incluso los condicionales se pueden hacer. Y lo realmente bueno es correrlos en computación normal, ¿no? Yo tengo una computadora. Tú tienes una computadora. Nada de blockchain. Si tú tienes un sistema SAP y yo tengo un Microsoft Dynamics, y este otro tiene una hoja de cálculo, podemos hacer cosas en computadoras normales con conocimiento cero. Poner zero-knowledge sobre blockchain es como poner una cosa extraordinariamente cara computacionalmente encima de otra cosa extraordinariamente cara computacionalmente, lo cual no tiene mucho sentido para mí. Aunque, gracias, dinero de las apuestas, por pagar tanta investigación en zero-knowledge. Muchas gracias.
Kevin Pues aquí va mi pero: ¿qué pasa con los verificadores? Básicamente, pones un hash en la chain, como diciendo: bueno, que nadie manipule ese hash, igual que con el verificador, para que la prueba realmente se valide de forma correcta. Si lo tienes en una computadora, claro que lo puedes cambiar.
John Probablemente puedes hacer eso. Sin duda puedes generar tu prueba de conocimiento cero y hacer tu circuito en una sola computadora. Y las firmas digitales, eso sabemos hacerlo. Es bastante trivial. Pero luego, sí, ¿dónde pones la prueba? Y no necesitas verificar la prueba. Puedes simplemente guardarla en un sistema resistente a manipulación. Y si además quieres correr un verificador en una blockchain, genial, perfecto, pero no tienes por qué. Y además es caro. Entonces, ¿para qué hacerlo si puedes hacerlo de forma más eficiente en computación normal?
Kevin Ese quizá sí es ahora un gran pero de verdad, ¿no? Básicamente se trata de entender: ¿realmente necesito asegurarme de que el verificador no esté siendo manipulado? Los dos sabemos que para el 99 por ciento de todos los casos está perfectamente bien tener el verificador en un simple archivo JavaScript normal o lo que sea, en tu propia computadora, en un servidor. Pero quizá.
John Bueno, también puedes, con algo como un SBOM, un software bill of materials, o un bill of lading. O sea, hay maneras de lograr el objetivo que buscamos con eso, simplemente diciendo: bueno, el verificador es un sistema de alto rendimiento, y aquí está centralizado, pero también es observable, ¿no? Y podemos hacerle hashing de estado continuamente, y podemos tener gente observándolo. Y desde luego, para un grupo de empresas que intentan asegurarse de que nadie le está haciendo trampas a nadie, es perfectamente válido. Y, ya sabes, hay mucho de esto. A mí me ha costado muchísimo encontrar casos de uso donde necesite descentralización suprema en absolutamente todo. Simplemente no lo veo.
Kevin Pero sí, justo eso que mencionas de los verificadores va un poco en esa dirección, ¿no? Al final siempre es cuestión de cuántos recursos tenemos que meter también. Ese es un encuadre que también me gusta mucho. Blockchain es un activo. Es una infraestructura que ya existe, ¿no? Cuando tienes que construir tú mismo esos sistemas semidescentralizados, inventarte un concepto de lógica para eso, quizá requiere más trabajo que simplemente desplegar ese verificador sencillo en la chain. Así que quizá ahí podría ser útil.
John Claro. El problema es que hemos estado absorbiendo a un montón de desarrolladores nuevos, de a pie, ¿no?, que se emocionan con lo nuevo. Y el POC funciona bien, y es emocionante. Es fácil. Bueno, no siempre fue tan fácil, pero estás como: ah, voy a usar un smart contract. Cualquiera que lleve tiempo en esto sabe que un smart contract es básicamente un procedimiento almacenado sobre un ledger. Procedimientos almacenados llevamos haciéndolos en sistemas Oracle desde hace mil años, desde los noventa. Ya entonces no nos gustaban. Los procedimientos almacenados realmente no son eficientes, no son una buena manera de hacer lógica de negocio sobre un conjunto de datos. No es una gran manera, normalmente.
John Pero, ya sabes, Vitalik dijo: oigan, hagamos smart contracts sobre una blockchain, y eso abrió todo esto. Y claro, sí, si pudiera escalar, o si después no hubiéramos salido de repente a crear un montón de valores financieros sin llamarlos valores y a desplumar a un montón de abuelas, habría sido fantástico, ¿no? Pero resulta que los procedimientos almacenados como patrón de diseño no son ninguna maravilla si puedes lograr el objetivo de otra manera. Pero ahora, sí, hay mucha gente emocionada con los smart contracts, porque les hemos estado diciendo que se emocionen con los smart contracts. Y yo vengo a decir: oye, piensa por ti mismo, y no dejes que los maestros del hype de blockchain te engañen para apoyar algo simplemente porque quieren que su moneda suba.
Kevin Siempre es, si vas justo al principio: qué intenciones, ¿no? Eso es de hecho algo muy triste de ver, que mucha gente predica lo que no es, ¿verdad? No se mantienen fieles a la visión que publican, y básicamente hacen otra cosa, ¿no? Tienen todos esos recibos, y luego los dejan caer sobre el retail y la gente. Todas estas cosas, al final, se reducen a, ya sabes, malas intenciones.
John Es difícil discutírtelo. Es difícil ir en contra de tu bolsillo, ¿no? Y yo pasé ocho años intentando con toda honestidad encontrar alguna forma no-crypto de usar una blockchain. Y al final del día, cuando no pude, cuando me quedé sin peros, dije: oigan, me quedé sin peros. Y lo dije abiertamente. Y no a todo el mundo le encantó. Es curioso, a los degens les encantó, porque escribí blockchain bien, y eso era todo lo que quería. Pero los que intentaban venderles esto a las empresas, no creo que le vieran mucha gracia. Me llovieron algunas críticas de su lado. Pero lo interesante es que un día estaba en una llamada con un profesor, y no voy a decir quién es, por el bien de su carrera. Y le dije: mira, creo que sé de sistemas distribuidos, pero sé que tú sí sabes. Y es un profesor muy famoso, un profesor con cursos enormes sobre blockchain, cientos de miles de personas, libros sobre blockchain, todo eso. Y le dije: no creo que podamos escalarlo, y no creo que las layers ni ZK ni ninguna de estas cosas realmente lo resuelva para ninguno de los casos de uso que estamos proclamando. ¿Por qué estoy equivocado? Si me puedes mostrar por qué estoy equivocado, cambio de postura al instante, porque creo que tú sabes de lo que hablas. Y me dijo: no, claro que tienes razón. Pero no puedo decirlo. Porque el decano cree que podemos seguir vendiendo más cursos de blockchain.
John Ese fue el momento para mí. No se trata solo de que la moneda suba. Es, ya sabes, necesito tener más cursos, que consigamos que la gente se crea esto. El crypto siempre fue crypto. Pero una estafa tecnológica no la puedo tolerar. No te voy a mentir sobre mis hallazgos en la experiencia tecnológica. Puedo ser ingenuo. Puede que todavía no sepa algo. Puedo estar emocionado con algo. Estuve emocionado, estoy emocionado con blockchain por muchas razones. La mayoría de esas razones son válidas. Es solo que nos pusimos, yo me puse, todos nosotros, nos pusimos en modo solución. Dijimos: oye, aquí está mi martillo, ¿dónde está tu clavo? Y resultó que las afirmaciones que hacíamos sobre la tecnología en sí estaban equivocadas, y era fácil ver que estaban equivocadas. Solo que, madre mía, había mucho dinero. Había muchísimo dinero.
Kevin Okey. ¿Y qué piensas de esos enfoques alternativos de DLT? ¿Crees que es exactamente lo mismo, básicamente, tipo hashgraphs y ese tipo de cosas? Solo para conocer tu opinión sobre eso también.
John Bueno, volviendo a la regla de los dos peros, la pregunta es: ¿qué necesidades hay detrás de tu intención? Si tu intención es hacer un hashgraph o algo así, realmente deberías centrarte en qué necesidades intentas resolver, y luego olvidarte del hashgraph o de cualquier otra cosa, incluida la IA, lo que sea, y decir: ¿qué herramientas hay ahí fuera para llevarme a la meta con mis intenciones? Y aparecen un montón de peros gordos, difíciles de superar, si dices: tengo que hacerlo con la cosa X. Ya sabes, oye, estoy poniendo un cristal, estoy colgando vidrio, ¿no? Toma, un martillo. Quizá no es la herramienta adecuada.
Kevin Eso es realmente, ¿sabes, John?, decir eso también en público. Eso es lo que de verdad me encanta de nuestras conversaciones, porque como dije también en nuestra historia de Instagram, eres muy directo. Dices lo que piensas. Y tienes esta, si puedo decirlo así, actitud de no bullshit. Realmente piensas a través de todo ese, digamos, ruido, y te centras en lo que importa, ¿no?
John Yo te voy a dar bullshit. Pero con suerte, en cuanto me dé cuenta de que es bullshit, te diré que era bullshit. No soy inmune al bullshit. Ninguno lo somos. Pero en cuanto lo veo claro, tiendo, estúpidamente, a avisarle a la gente de que estaba hablando pura mierda. Y lo único que podemos hacer es mantener la mente abierta.
Kevin Yo debería ser tan abierto como pueda, ¿sabes? Y de verdad intento meterme a fondo en todas estas perspectivas distintas. Y, ya sabes, me encanta. Gracias por compartir todo esto.
John Gracias a ti. Eres muy reflexivo en tu programa y en tu trabajo, y eres un gran líder, en mi opinión. Así que sigue así. Me encanta parte de lo que has estado publicando sobre el trabajo que haces con gente joven. Es fantástico. Intenta no meterlos demasiado en el crypto, por favor. Aunque, ya sabes, la hegemonía del crypto necesita de verdad que la próxima generación intercambie bienes y servicios por sus tokens de bonos al portador. Quizá sí, quizá no. Pero bueno. Gracias.
Kevin En cualquier caso, gracias, John, por tu tiempo. Fue un verdadero placer.
John Gracias, hombre. Qué gusto verte.
Kevin Este sí que fue un episodio de locura. Creo que Ernesto está de acuerdo conmigo en eso. Bueno, de verdad aprecio mucho a John, y he trabajado con él en el pasado. Y si me ves publicando sobre este enfoque no bullshit, sobre construir productos que tengan sentido: mucho de eso en realidad lo aprendí de John. Así que estoy profundamente agradecido por mi experiencia de trabajo con él, y más todavía por que se haya tomado el tiempo de hablar conmigo hoy en nuestro podcast. Y sí, aunque claro que no estoy de acuerdo con todo lo que dice sobre blockchain, como oíste, con muchas cosas sí, sobre todo en cuanto a dónde blockchain tiene sentido de verdad y dónde no, disfruté muchísimo, muchísimo esta conversación. Y quizá hasta la vuelva a ver yo mismo, porque creo que hay ciertas joyitas escondidas que, durante la conversación, quizá ni yo mismo escuché. Así que cuéntanos qué te pareció el podcast. Deja un comentario abajo, suscríbete, dale al like, lo que sea. Muchísimas gracias. De verdad ayuda a nuestro canal. Y sí, échale un ojo al libro de John, sin duda. Yo tuve el placer de leer la versión gratuita antes de que saliera, así que de verdad lo puedo recomendar. Recomiendo el libro. Y nada, gracias por vernos.
Construimos MVPs y trabajamos como CTOs fraccionales para fundadores que prefieren lanzar antes que hablar.