Durante décadas, diseñar un producto digital era, en gran parte, decidir dónde poner los botones.

Un buen botón tenía que ser claro, accesible, visible. La interfaz era una coreografía visual entre lo que el usuario necesitaba y lo que el producto podía ofrecer. Y el lenguaje de esa coreografía eran menús, iconos, formularios, sliders. Nos acostumbramos a trabajar bajo la idea de que el usuario tenía que aprender “cómo se usa” una herramienta.

Eso se acabó.

Con la irrupción de los modelos de lenguaje y las experiencias conversacionales, estamos entrando en una nueva etapa: el producto como diálogo. Y con ello, la experiencia discreta (basada en opciones prediseñadas) da paso a una experiencia continua (basada en intenciones y contexto).

Del botón al contexto

En mitad de la conversación con Javier Vélez, no pude evitar soltarlo:

“El gran holocausto de esta revolución va a ser la eliminación de muchos botones.”

Y lo sostengo. Si la máquina entiende lo que quiero decirle, ¿para qué necesito que me dé una lista de botones preaprobados? ¿Por qué tiene que haber una papelera para borrar o un lápiz para editar, si puedo simplemente pedir “borra esto” o “cambia esto”?

La experiencia deja de estar prepartida en bloques de funcionalidad y pasa a ser una conversación viva con una herramienta que me entiende, razona, pregunta y actúa.

Esto no es simplemente una tendencia de UI. Es un cambio de paradigma.

El fin de la interfaz como la conocíamos

Durante años, UX ha sido una traducción: del pensamiento humano al lenguaje de la máquina. Y en esa traducción, los botones jugaron un papel central. No por casualidad: los heredamos directamente del mundo físico. En las máquinas industriales, los controles eran botones físicos, interruptores, palancas. El botón era la forma más explícita y binaria de operar un sistema: encender, apagar, aceptar, cancelar. Cuando el software empezó a reemplazar a las interfaces mecánicas, simplemente las copiamos. Así nacieron los botones digitales: como metáforas visuales de los mecanismos físicos que ya conocíamos. Esa herencia definió cómo se construyó el software durante décadas. Pero ahora, por primera vez, tenemos tecnología capaz de operar más allá de lo binario, más allá del “haz esto o lo otro”. Ahora ocurre lo contrario: es la máquina la que se está adaptando a nosotros.

Ya no diseñamos interacciones cerradas, sino espacios de entendimiento. Ya no pensamos en flujos estáticos, sino en contextos dinámicos. Y, como consecuencia, el foco del diseño se desplaza desde la superficie hacia el núcleo semántico del producto.

Los caminos predefinidos (“paso 1, luego paso 2, luego confirmación”) empiezan a diluirse. El usuario no tiene que seguir un flujo; puede expresar lo que necesita en sus propios términos. El producto debe ser capaz de reinterpretar y responder, no solo de ejecutar. Ya no diseñamos pantallas, diseñamos diálogos. Y eso exige otro tipo de sensibilidad: entender cómo se formula una intención, cómo se responde con precisión y cómo se construye una experiencia que se siente natural, pero sigue estando controlada y guiada. El trabajo de un product manager o diseñador deja de ser definir qué botones debe tener la pantalla, y pasa a ser definir qué capacidades debe tener la máquina para entender al usuario. El diseño es semántico, no visual. El producto es un sistema de interpretación, no una maqueta navegable.

No todo es una caja de texto

Ahora bien, el péndulo no debe irse al extremo. Como advertimos en el episodio, uno de los riesgos actuales es pensar que basta con poner “una caja de chat” y darle poder a un modelo de lenguaje. El resultado es a menudo una experiencia ambigua, opaca o frustrante.

Diseñar buenos productos dialógicos no es lo mismo que reemplazar tu producto con un GPT en una caja gris. Se trata de crear experiencias que:

* entienden la intención del usuario,

* saben hacer follow-up,

* tienen agencia,

* y están perfectamente alineadas con los límites del sistema.

Aquí es, dónde pensar qué quiero hacer con el producto, cobra más importancia que nunca. Las decisiones ya no están en la estética ni en el layout, sino en cómo modelamos intenciones, acciones y respuestas. Es diseño de comportamiento.

¿Qué hacemos con todo lo aprendido?

Todo lo que sabíamos de UX, arquitectura, design systems y flows no desaparece. Pero ya no es suficiente.

Estamos entrando en la era de los productos centrados en lenguaje y habilitados por inteligencia. Una era donde el valor no está en el pixel-perfect, sino en la capacidad del sistema de conversar y resolver. Una era donde diseñar un producto no es hacer que el usuario aprenda cómo usar la herramienta, sino hacer que la herramienta entienda al usuario.

🎧 ¿Quieres profundizar?

Este artículo nace de una conversación con Javier Vélez, experto en estrategia tecnológica y transformación digital. En el último episodio de Tenemos que hablar de producto, hablamos sobre:

* cómo la IA reconfigura el diseño de producto,

* qué va a pasar con las interfaces tradicionales,

* y por qué el futuro no es un botón, sino una intención bien entendida.

👉 Puedes escuchar el episodio completo en YouTube o en tu plataforma favorita.

Te prometo que, después de escucharlo, te vas a replantear más de un Figma.

Hay algo casi mágico en ver cómo una decisión tomada desde el dato correcto transforma una experiencia de usuario. No es magia, claro. Es analítica digital bien hecha.

Pero ¿cuántas veces creemos estar midiendo bien… cuando en realidad solo estamos sumando eventos?

En equipos de producto, hablar de datos es fácil. Lo difícil es medir lo que realmente importa: ese momento de fricción en el funnel que parece invisible, ese comportamiento del usuario que se diluye entre dashboards.

Medir bien no es coleccionar KPIs. Es saber hacer la pregunta correcta y construir el sistema adecuado para responderla. Medir bien es una decisión de diseño.

¿Qué significa medir bien?

* Medir bien es priorizar la comprensión sobre el volumen.

* Medir bien es evitar el vanity data y centrarse en el comportamiento.

* Medir bien es tener claridad sobre lo que se quiere accionar después del insight.

No se trata de tener una herramienta cara ni de montar un stack sofisticado. Se trata de cultura. De saber que sin una buena medición, las decisiones de producto son, en el mejor de los casos, apuestas intuitivas.

En Decathlon lo tienen claro

Tuve la suerte de conversar con Jorge López, Head of Digital Analytics en Decathlon España, y hablar de todo esto. De cómo entienden el rol del dato, de cómo usan Amplitude, y de cómo han logrado identificar puntos críticos en el funnel de conversión que no eran visibles con herramientas tradicionales.

👉 Puedes ver la entrevista completa aquí:

Si estás en un equipo de producto, datos o UX, creo que te va a dar buenas ideas y quizá alguna inspiración.

“Un mal producto con buena gestión financiera no va a ningún lado. Pero un buen producto con mala gestión… te pierde el partido.” — Jaime Medina, CEO de Startup CFO

Hace unos días grabamos un episodio con Jaime Medina, fundador de Startup CFO, en el que hablamos sobre un tema que rara vez se discute con profundidad: la relación entre el equipo de producto y el CFO.

En el ecosistema startup estamos muy acostumbrados a pensar en producto como algo casi autónomo: diseño centrado en el usuario, decisiones basadas en datos de uso, discovery continuo… pero, ¿cuántas veces involucramos a Finanzas de verdad?

Jaime tiene una visión muy clara: el CFO no está para revisar facturas ni hacer reporting por obligación. Está para ayudar a tomar mejores decisiones. Especialmente, las de producto.

💸 El CFO no es un deliverable. Es una herramienta estratégica

Uno de los mensajes más potentes de Jaime fue este: el reporting no es el trabajo del CFO, es su herramienta. No sirve para entregar un PDF cada mes, sino para detectar que estamos invirtiendo en la dirección equivocada, o que estamos gastando sin retorno real.

"¿Por qué estamos metiendo pasta en inbound si outbound tiene mejor conversión?"

En otras palabras, el CFO tiene que estar tan cerca del negocio como del Excel.

🔁 ¿Tu producto es recurrente o simplemente lo quieres creer?

Otra joya que dejó Jaime es la crítica al sesgo aspiracional que tenemos en producto (y como founders): creer que tenemos un modelo de negocio recurrente cuando en realidad el caso de uso no lo es.

Puedes cobrar por suscripción. Pero si el usuario solo tiene necesidad una vez al año, tienes un problema de retención disfrazado de MRR.

“Imagínate que haces un SaaS para organizar bodas. Por muy recurrente que quieras que sea… no lo es.”

📊 Habla el idioma del CFO (si quieres que te aprueben el roadmap)

¿Quieres convencer al CFO de que priorice una funcionalidad? Jaime fue muy claro: habla en términos de retorno de inversión.

* ¿Cómo afectará esa funcionalidad al churn?

* ¿Reducirá el cash payback?

* ¿Incrementará el ticket medio?

La clave está en presentar las apuestas del roadmap como escenarios con impacto financiero estimado, no solo como mejoras de UX.

🧪 Elimina incertidumbre, pero con cabeza

Finalmente, Jaime recuperó la esencia del enfoque lean: una startup es una máquina de eliminar incertidumbre. Pero no lo haces por intuición, lo haces con datos. Y si los datos no están, al menos modela hipótesis con rangos, escenarios, riesgos.

“Apunta al caso optimista, toma decisiones en el base, y finańciate para el peor.”

🧠 ¿Qué debería hacer un Product Manager diferente mañana?

* Agenda una reunión con Finanzas. En serio. Conócelos, explícales tu mundo.

* Comparte tus métricas de uso con contexto financiero.

* Empieza a pensar en unit economics. Pero desde el cash.

* Usa cohortes, no averages. No caigas en la trampa de la “media de la teta y el huevo”.

* No compres features milagro. Mide. Compara. Decide.

Este episodio es oro puro si alguna vez te has preguntado: ¿cómo puedo justificar el impacto de producto más allá de lo cualitativo?

Puedes escucharlo completo aquí →

Últimamente todo lo que escuchamos sobre inteligencia artificial tiene que ver con prompts, ChatGPT, generación de imágenes o vídeos. Pero hoy quería traeros una conversación muy distinta.

Invité a Daniyal Shahrokhian al podcast para hablar de la otra IA.La que no se hace viral en redes, pero que se lleva usando desde hace años para resolver problemas reales en empresas. La que requiere datos bien montados, procesos duros de entrenamiento, validación y precisión. Y la que —aunque no tenga nombre de chatbot— mueve millones.

Durante una hora hablamos de:

* Cuál es la diferencia real entre IA generativa y la que él llama "discriminativa".

* Qué tipo de datos se usan para entrenar modelos en el mundo real (y por qué eso es más difícil de lo que parece).

* Cómo funcionan técnicas como el transfer learning y qué es eso de congelar capas de un modelo.

* Qué retos hay al aplicar IA en industrias como la farmacéutica.

* Y por qué el mayor problema no es montar el modelo, sino conseguir y limpiar los datos.

Me gustó mucho una reflexión de Dani:

“No aprendas IA porque sí. Aprende IA cuando veas un problema concreto que quieras resolver. Así es como realmente se aprende.”

Si te interesa entender cómo se aplica la IA más allá del hype, o si estás pensando en usarla en tu empresa, te recomiendo que lo escuches entero.

🎧 Aquí tienes el episodio completo →

El otro día entrevisté a Álvaro Gil, analista de datos en Mojang Studios, la empresa detrás de Minecraft, y aún sigo pensando en todo lo que aprendí.

Imagínate tener que analizar el comportamiento de más de 300 millones de jugadores, cada uno con su estilo, su ritmo y su forma única de jugar. Ahora imagina que de ese caos tienes que sacar ideas claras que ayuden a mejorar el juego más vendido de la historia. Eso es lo que hace Álvaro cada día.

Durante la conversación hablamos de todo:✅ cómo funciona el equipo de Data Analytics dentro de Mojang,✅ qué tipo de datos se recopilan en el juego (¡sin saber la edad ni el género del jugador!),✅ cómo usan plataformas como Databricks para manejar volúmenes gigantes de datos,✅ y cómo han conseguido que los desarrolladores usen los datos sin que se sientan dirigidos por ellos.

Uno de los momentos que más me gustó fue cuando hablamos de data storytelling. Álvaro lo explicaba con claridad: no basta con tener los mejores insights si nadie los entiende o si no sabes venderlos. En su día a día, eso significa a veces hacer presentaciones sin un solo número, porque lo importante es el mensaje, no el decimal.

También hablamos mucho sobre el papel de la inteligencia artificial en su trabajo. Spoiler: no va a reemplazar a los analistas, pero sí les va a liberar mucho tiempo para centrarse en lo que realmente importa: pensar mejor, entender el contexto, trabajar con los stakeholders y aportar valor más allá del código.

💡 Si estás en el mundo del análisis de datos, el diseño de producto, el desarrollo o el gaming, este episodio es para ti.

👉 Puedes ver el episodio completo aquí:

Nos vemos en el próximo.

Hace tiempo que quería hablar con Ignacio Arriaga. Lo conocí por su newsletter, Disaaster —sí, con dos aes—, donde escribe con una honestidad brutal sobre software, negocio y producto. Pero, sobre todo, porque ha hecho algo que pocos pueden decir: construir un SaaS rentable, sin inversión, desde Ciudad Real. Y seguir al frente, 13 años después.

Hace unos días compartí un clip de Ignacio en el que decía algo que me dejó clavado:

“Aceptar que tienes un negocio de puta madre con margen alto… reestructúrate un poco. Igual no vas a crecer tanto. ¿Y qué?”

La frase tocó un nervio. La publiqué y la reacción fue inmediata: mensajes, reposts, debates.Parece que somos muchos los que estamos empezando a hacernos esa misma pregunta en voz alta.

La enshitification del SaaS

En esta entrevista hablamos del concepto de enshitification: esa palabra que suena tan mal como la situación que describe. La degradación progresiva de un producto por culpa de decisiones centradas en las ventas y no en el usuario.

Ese momento en el que un producto que era bueno empieza a estropearse, no por falta de talento, sino por decisiones centradas en contentar a inversores, justificar estructuras, o inflar el ticket medio.

Y cuando eso pasa, todo se resiente: la experiencia, la percepción de valor, el pricing… incluso el equipo.

Crecer no es gratis (ni siempre es bueno)

Ignacio tiene una perspectiva valiosísima: ha dirigido Acumbamail durante más de 13 años, sin inversión externa, con un equipo pequeño y un producto que sigue siendo relevante y rentable.

Durante la charla hablamos de:

* Por qué muchas empresas SaaS acaban traicionando a sus propios usuarios.

* Cómo el equipo de ventas puede pervertir la evolución de un producto.

* Qué significa crecer por encima de tus posibilidades reales.

* El nuevo hype de la IA y cómo está volviendo a justificar crecimientos absurdos.

“Solo hay una cosa que crece de forma infinita: el cáncer.”— Ignacio Arriaga

Mi lectura personal

* No todo crecimiento es sano.

* No todos los productos necesitan escalar para ser buenos.

* Y muchas veces, la obsesión por escalar destruye lo que funcionaba.

Puedes escuchar la entrevista completa aquí:

→ ¿Te gusta el contenido? Suscríbete a mi canal de YouTube y apoya al podcast.

→ ¿Quieres venir a hablar al podcast? Contesta a este email.

Si trabajas en un equipo de producto o desarrollo, seguro que alguna vez has sentido que hay una especie de trinchera entre ambos mundos. Los product managers pidiendo rapidez, los desarrolladores exigiendo calidad, las fechas de entrega tensando la relación... Vamos, un clásico.

Por eso, cuando tuve la oportunidad de entrevistar a Raul Gonzalez, CTO y asesor tecnológico, no dudé en preguntarle sobre cómo mejorar la colaboración entre producto y desarrollo. Raúl ha trabajado con startups y scale-ups ayudando a construir equipos técnicos eficientes y alineados con el negocio. Así que, si alguien sabe de esto, es él.

¿Por qué hay tantas fricciones entre producto y desarrollo?

Le pregunté directamente: ¿Dónde están las mayores tensiones entre estos dos equipos? Y su respuesta fue clara: viene de lejos.

Raúl explica que la estructura tradicional de trabajo en cascada dejó una herencia difícil de romper. Antes, producto definía los requisitos y los pasaba a desarrollo como si fueran una fábrica, sin apenas interacción. Con la llegada de Agile, en teoría, esto cambió. Pero, en la práctica, aún vemos equipos trabajando en silos, sin entenderse del todo.

También me habló de un error común: pensar que el delivery es solo cosa de desarrollo. En realidad, entregar producto es una misión de equipo, y cuando no se entiende así, empiezan los problemas.

Aquí Raúl usó una metáfora que me pareció muy acertada: en un equipo de fútbol, defender no es solo tarea de los defensas. Si el equipo entero no colabora en la defensa, tarde o temprano recibirán goles. Lo mismo pasa en los equipos de producto: si desarrollo y producto no trabajan juntos en la entrega, el resultado será un caos. Todos deben asumir la responsabilidad del éxito del producto, sin delegar completamente en el otro equipo.

Velocidad vs. Calidad: ¿Se puede tener todo?

Uno de los grandes conflictos entre producto y desarrollo es el equilibrio entre ir rápido y hacer las cosas bien.

Raúl lo dejó claro: la calidad es lo que te permite ir rápido a largo plazo. Un equipo que construye con calidad desde el principio evita problemas futuros, reduce la deuda técnica y puede moverse con más agilidad. Pero claro, eso implica tomar buenas decisiones sobre cuándo y cómo asumir deuda técnica.

Aquí soltó una comparación que me encantó: la deuda técnica es como una deuda financiera. Si la usas bien, te da un impulso; si abusas de ella, acabas ahogado.

Cómo mejorar la colaboración entre producto y desarrollo

Si tuviera que quedarme con tres ideas clave de la entrevista, serían estas:

* Construir un equipo de verdad. No basta con juntar a product managers y desarrolladores en la misma reunión. Hay que generar confianza, empatía y propósito compartido.

* Los desarrolladores deben entender negocio y los PMs tecnología. Si cada equipo solo habla su propio idioma, la comunicación se rompe. Raúl insiste en que los ingenieros deberían hablar con usuarios y los PMs deberían entender las implicaciones técnicas de sus decisiones.

* Eliminar la mentalidad de silos. Producto no es el enemigo de desarrollo y viceversa. Los mejores equipos trabajan con una visión común y desafían mutuamente sus ideas para llegar a mejores soluciones.

Raul ha sacado un playbook sobre como escalar tu equipo que es una pasada! Echale un ojo aquí!

Si alguna vez has sentido fricción entre producto y desarrollo en tu empresa, te recomiendo que veas la entrevista completa. Hay ideas súper valiosas para cualquier equipo que quiera trabajar mejor y entregar producto sin tanto drama.

🔗 Mira la entrevista completa aquí:

→ ¿Te gusta el contenido? Suscríbete a mi canal de YouTube y apoya al podcast.

→ ¿Quieres venir a hablar al podcast? Contesta a este email.

Si hay un conflicto que se repite en casi todas las empresas de producto, es el de marketing contra producto. Dos mundos que deberían estar alineados y, sin embargo, muchas veces parecen rivales en una pelea de egos y prioridades. Para hablar de esto, me senté con Luis Encabo, un experto en marketing y ventas con experiencia en empresas como ThePowerMBA, además de haber montado su propia agencia. Y, como era de esperar, la conversación fue directa, sin filtros y con algún que otro momento de "tensión divertida".

¿Por qué nos llevamos mal?

Empezamos con una pregunta directa: ¿Por qué hay tantas fricciones entre marketing y producto? Según Luis, la clave está en que muchas veces no hablamos el mismo idioma. Marketing se enfoca en la captación y en vender, mientras que producto quiere construir con lógica y sin promesas excesivas. Y aquí viene la pregunta clave: ¿quién tiene razón?

Luis no se anduvo con rodeos: ambos fallan. Si producto no comunica bien lo que está construyendo y sus limitaciones, marketing improvisa y vende cosas que no existen (o que no funcionan como deberían). Si marketing no entiende bien el producto, crea mensajes vacíos que no generan ventas.

El mito del "marketing vende humo"

Uno de los puntos que más me interesaba discutir con Luis era este mito recurrente: Marketing promete cosas que producto no puede entregar. Y su respuesta fue clara: no es que marketing "venda humo", es que muchas veces no tiene la información necesaria para saber qué puede vender de verdad.

Aquí es donde las empresas que mejor funcionan marcan la diferencia: producto y marketing tienen que trabajar juntos desde el inicio. Si el equipo de marketing no conoce bien el producto y lo que realmente aporta al usuario, está condenado a generar mensajes irrelevantes o que no convierten.

¿Cómo solucionamos esta guerra eterna?

Le pedí a Luis consejos prácticos para que producto y marketing dejen de ser rivales y empiecen a remar juntos. Su respuesta se puede resumir en tres puntos clave:

* Marketing y producto deben entenderse mutuamente. Si trabajas en marketing, habla con el equipo de producto y prueba el producto. Si trabajas en producto, involúcrate en las estrategias de captación y conversión.

* Sesiones de trabajo conjuntas. No vale con enviar un brief o un documento por Notion. Hace falta sentarse juntos y entender cómo alinear los objetivos.

* Validación constante. No lances funcionalidades sin saber cómo se van a comunicar. No hagas campañas sin estar seguro de que el producto lo respalda.

¿Cuándo entra marketing en el desarrollo de producto?

Otro debate interesante fue el de cuándo es el momento adecuado para que marketing se involucre. ¿Desde el día uno o cuando ya hay algo tangible? Luis lo tiene claro: cuanto antes, mejor. Y puso un ejemplo brutal: hoy en día, con herramientas como Facebook Ads, puedes validar una idea sin necesidad de desarrollar el producto. ¿Por qué esperar meses para saber si algo interesa al mercado?

En resumen, marketing y producto no son equipos separados. Son dos partes de la misma ecuación y, si no trabajan juntos, el resultado será siempre el mismo: mala comunicación, clientes confundidos y oportunidades perdidas.

Si te ha parecido interesante esta conversación, te recomiendo que veas el episodio completo en YouTube. Luis compartió ejemplos muy concretos y consejos prácticos que seguro pueden ayudarte a mejorar la relación entre marketing y producto en tu empresa.

→ ¿Te gusta el contenido? Suscríbete a mi canal de YouTube y apoya al podcast.

→ ¿Quieres venir a hablar al podcast? Contesta a este email.

En el último episodio de Tenemos que hablar de producto, tuve la oportunidad de entrevistar a Eugenio García-Calderón, ingeniero, activista y emprendedor, que ha dedicado su trayectoria a transformar el acceso a la energía a través de la innovación y la descentralización. Desde su activismo contra el "impuesto al sol" hasta la fundación de Light Humanity y su trabajo en comunidades energéticas, Eugenio nos comparte una visión ambiciosa: conectar el mundo físico con el digital para democratizar la energía y la financiación.

El camino de Eugenio en la energía sostenible comenzó con una bicicleta impulsada por paneles solares con la que recorrió España en protesta contra las barreras al autoconsumo. Su activismo lo llevó a fundar Light Humanity, una organización que en sus inicios combinaba un modelo de empresa y ONG para llevar soluciones solares a comunidades del Amazonas y África.

Sin embargo, con el tiempo, comprendió que las donaciones no eran la solución escalable. "Cuando regalas algo, la gente lo usa, pero no lo valora ni lo mantiene", nos contó. Ahí nació la idea de convertir la energía en un producto financiado y accesible, en lugar de una simple ayuda.

Para escalar el acceso a la energía, Eugenio fundó Solar Crowd, un sistema de microfinanciación donde personas con ahorros pueden prestar dinero para instalar sistemas solares en comunidades sin acceso a electricidad. A cambio, reciben un interés que los beneficiarios pagan con los ahorros generados por el uso de energía solar en lugar de combustibles fósiles.

Sin embargo, la falta de trazabilidad en los proyectos financiados llevó a una evolución clave: la adopción de blockchain para garantizar transparencia y escalabilidad. Gracias a esta tecnología, los sistemas solares que instala Light Humanity ahora funcionan en modo prepago: si el usuario no ha pagado su cuota, el sistema simplemente deja de funcionar. "El modelo de prepago es clave para la sostenibilidad. Así evitamos impagos y aseguramos la continuidad del sistema", explicó.

Lo más fascinante de la visión de Eugenio es cómo ha unido blockchain, energía y financiamiento en un ecosistema donde un panel solar no es solo un generador de electricidad, sino un activo digital con valor financiero. "Si puedes demostrar que hay un flujo constante de dinero en una wallet asociada a un sistema solar, tienes una prueba de valor real, un 'proof of value' que da confianza a inversores sin necesidad de intermediarios", nos explicó.

Esto resuelve un problema clave de la financiación energética: en muchos países en desarrollo, los bancos tradicionales no prestan dinero o lo hacen a tasas desorbitadas. Con este sistema, una persona en Madrid puede invertir en un sistema solar en Mozambique sin necesidad de confiar en bancos ni en intermediarios locales.

Eugenio no solo nos dejó una conversación muy interesante sobre tecnología y energía, sino también una visión clara de cómo el futuro de la energía no está en las grandes corporaciones, sino en las comunidades y en la capacidad de los ciudadanos para ser dueños de su propia producción.

El reto ahora es escalar este modelo y demostrar que la descentralización no solo es viable, sino necesaria para la transición energética global.

→ ¿Te gusta el contenido? Suscríbete a mi canal de YouTube y apoya al podcast.

→ ¿Quieres venir a hablar al podcast? Contesta a este email.

En este episodio de Tenemos que hablar de producto, conversé con Marc, fundador de WeUp, una startup que optimiza la gestión de contenido en LinkedIn. Su historia es un ejemplo de aprendizaje y adaptación.

Por esta colaboración especial, además de los 7 días gratis en WeUp, tendrás acceso a una reunión exclusiva de onboarding y consultoría con uno de los fundadores, para que puedas mejorar tu estrategia en LinkedIn.Solo regístrate en WeUp y responde al primer correo con “¡Me encanta el producto!”.

Marc nunca encajó del todo en la educación tradicional. Tras acabar el bachillerato, se orientó hacia el desarrollo web y descubrió su pasión por la programación. Comenzó en Indra, pero pronto se dio cuenta de que necesitaba un reto diferente. Así llegó a la ciberseguridad, donde consiguió su primer trabajo en el sector sin experiencia previa. Después pasó por compliance y ventas, un área en la que destacó por su capacidad para conectar con clientes. Pero su inquietud por emprender seguía ahí.

Junto a un excompañero, exploró diversas ideas hasta aterrizar en la inteligencia artificial aplicada al contenido en redes. Inicialmente, WeUp era un proyecto demasiado ambicioso, así que decidieron reducir su alcance y validar la idea antes de desarrollarla.

Para evitar desarrollar sin rumbo, crearon una web atractiva y hablaron con potenciales clientes. Descubrieron que a los negocios no les importaba la tecnología detrás del producto, solo querían una solución efectiva. Tras este aprendizaje, Marc dejó su empleo para dedicarse por completo a WeUp. La transición no fue sencilla, pero aprendió a gestionar su tiempo y avanzar con claridad. En enero lanzaron oficialmente. Un mes después, ya tenían cinco clientes y varias conversaciones avanzadas.

Marc lo tiene claro: valida antes de dejar tu trabajo. Muchas startups fallan por no confirmar la demanda. Su recomendación: construir una versión mínima, escuchar al mercado y ajustar antes de comprometerse completamente.

Ahora trabajan en mejoras basadas en feedback, nuevas funciones como carruseles en LinkedIn y más opciones de personalización.

Si te interesa probar WeUp, accede a su prueba gratuita en la web. Y si quieres conocer más sobre Marc y su trayectoria, no te pierdas el episodio completo del podcast.

→ ¿Te gusta el contenido? Suscríbete a mi canal de YouTube y apoya al podcast.

→ ¿Quieres venir a hablar al podcast? Contesta a este email.